Skip to content

Revert "Invalid non-blank line in synaptic.desktop.in:"#263

Closed
AsciiWolf wants to merge 1 commit into
mvo5:masterfrom
AsciiWolf:desktop-revert
Closed

Revert "Invalid non-blank line in synaptic.desktop.in:"#263
AsciiWolf wants to merge 1 commit into
mvo5:masterfrom
AsciiWolf:desktop-revert

Conversation

@AsciiWolf

@AsciiWolf AsciiWolf commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

This reverts commit 4e7668f.

The "_" prefixed lines in *.in files are automatically replaced with the translated ones by gettext. Removing them will mark these strings as non-translatable.

It is correct that msgfmt complains about them since *.in suffixed files are template files and are not supposed to be validated or installed directly. This is automatically handled during the compilation process, but I am not sure if it still works since you replaced autotools with meson recently. If it does not work, you have to fix it in the meson.build file - that's the correct way.

/cc @mvo5 @amaa-99

This reverts commit 4e7668f.

The "_" prefixed lines in *.in files are automatically replaced
with the translated ones by gettext. Removing them will mark these
strings as non-translatable
@mvo5

mvo5 commented Jul 22, 2026

Copy link
Copy Markdown
Owner

Hey @AsciiWolf ! Nice to see you and thanks for thanks for the PR! I was under the impression that the meson integration of gettext would no longer need the "_" - did I misread/misassume this? If so I'm of course happy to merge this.

@AsciiWolf if you have a bit of time I would love if you could play around a bit with the latest git version of synaptic - if all is well I would love to make a release soon(ish).

@AsciiWolf

AsciiWolf commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

I was under the impression that the meson integration of gettext would no longer need the "_"

Oh! It is possible, I am not an expert on meson. :) This needs to be tested (I can do it in upcoming weeks, but unfortunately not sooner; I will also test the git version of Synaptic as part of this).

@AsciiWolf

Copy link
Copy Markdown
Contributor Author

By the way, what about the AppStream metainfo file? It also has the "_" characters.

@AtesComp

AtesComp commented Jul 22, 2026

Copy link
Copy Markdown

FYI:
meson i18n gettext integration how to mark strings for translation in .in files

In Meson and GNU gettext, how you mark strings in .in files depends on the file type. For Desktop/Metainfo files, prefix the keys with an underscore _. For XML/GSettings files, add translatable="yes". Meson’s i18n module automatically handles extraction.

  1. Desktop and Metainfo Files (.desktop.in & .metainfo.xml.in)
    Prefix the translatable property or key with a single underscore _.
    Example (app.desktop.in):
[Desktop Entry]
Type=Application
_Name=My Application
_GenericName=Text Editor
_Comment=Edit your text files
Exec=app

Use code with caution.

  1. XML Files (.xml.in)
    For standard XML files, strings are marked using translatable="yes" attributes, often alongside an instruction set (ITS) file for gettext to parse them properly.
    Example (data.xml.in):
<?xml version="[1](https://github.com/mesonbuild/meson/issues/1565).0" encoding="UTF-8"?>
<component>
  <id>com.example.App</id>
  <name translatable="yes">My Application</name>
  <summary translatable="yes">A simple app summary</summary>
</component>

Use code with caution.

  1. GSettings Schemas (.gschema.xml)
    For schema files, use the translatable="yes" attribute on the <default>, <summary>, or <description> tags.
    Example (org.example.app.gschema.xml):
<?xml version="[1](https://discourse.gnome.org/t/xgettext-dont-extract-strings-from-ui-files/25063).0" encoding="UTF-8"?>
<schemalist>
  <schema id="org.example.app" path="/org/example/app/">
    <key name="greeting" type="s">
      <default translatable="yes">Hello World</default>
      <summary translatable="yes">A greeting message</summary>
      <description translatable="yes">The message shown to users on startup.</description>
    </key>
  </schema>
</schemalist>

Use code with caution.

  1. Meson Build Configuration (meson.build)
    To process these files and extract the marked strings, use i18n.merge_file() inside your Meson Build System configuration.
    Example (meson.build):
i18n = import('i18n')

# Desktop file
i18n.merge_file(
  input: 'data/app.desktop.in',
  output: 'app.desktop',
  type: 'desktop',
  po_dir: meson.project_source_root() / 'po',
  install: true,
  install_dir: get_option('datadir') / 'applications'
)

# Metainfo file
i18n.merge_file(
  input: 'data/app.metainfo.xml.in',
  output: 'app.metainfo.xml',
  po_dir: meson.project_source_root() / 'po',
  install: true,
  install_dir: get_option('datadir') / 'metainfo'
)

@mvo5

mvo5 commented Jul 23, 2026

Copy link
Copy Markdown
Owner

Thanks for the detailed examples. So I looked at the desktop file and it seems its getting it right and this revert is not needed? Maybe I'm missing something but I did (in

$ meson build
$ ninja -C build synaptic-pot
$ grep   -A3 "synaptic\.desktop\.in" po/synaptic.pot 
#: gtk/rgmainwindow.cc:2312 data/synaptic.desktop.in:3
#: data/io.github.mvo5.synaptic.metainfo.xml.in:7
msgid "Synaptic Package Manager"
msgstr ""
--
#: data/synaptic.desktop.in:4
msgid "Package Manager"
msgstr ""

#: data/synaptic.desktop.in:5 data/io.github.mvo5.synaptic.metainfo.xml.in:11
msgid "Install, remove and upgrade software packages"
msgstr ""

After applying the fixes from #269 - I think we are good and we don't need this PR.
The way meson extracts is plain xgettext/msgmerge, the previous autotools used
intltool, they just have different conventions: intltool needs the "_" but xgettext is
smater and knows the standard desktop keys so no need to mark e.g. name.

But let me know if I am missing something here, i18n is always a bit tricky :)

@AsciiWolf AsciiWolf closed this Jul 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants