Could you investigate a bit and collect some more information? In particular:
- Is it possible to automatically find out if a module is using intltool or plain gettext?
- When using plain gettext, what are the commands needed to produce a .pot file and for merging translations?
- Are POTFILES.in/POTFILES.skip still playing a role in the new process?

So here is an example commit: <https://git.gnome.org/browse/zenity/commit/?id=dc9719729899574d7f3b2056382af83fd106bd47>. I think it still uses POTFILES.in to generate POTFILES.

I guess you can check if configure.ac contains IT_PROG_INTLTOOL.

To make a .pot file, you need to run autogen.sh and then do "cd po && make zenity.pot". "cd po && make update-po" will update the .po files.

The GTK+'s script allows to update .po files without the messy autogen. I changed GETTEXT_PACKAGE="${GETTEXT_PACKAGE:-gtk30}" to GETTEXT_PACKAGE="${GETTEXT_PACKAGE:-zenity}" and tested it on zenity. It works fine.

> To make a .pot file, you need to run autogen.sh and then do "cd po && make zenity.pot". "cd po && make update-po" will update the .po files.

I always refused to go the "autogen.sh" route. If packages cannot build pot files from their plain sources, they are simply not supported by DL any more.

Maybe we should open bug reports against those packages so as their maintainers can suggest a proper way of generating pots.

Sure, we can go module-by-module and add a modified make-po script (or some other way to generate a .pot file in a clean manner), but IMHO it would be much more efficient to have it server-side.

The list of gettext-only modules will only grow, as maintainers are getting tired of intltool. So we can continue to enforce a broken, unmaintained tool, or embrace the change.

I'm all for embracing the change. I only regret that module maintainers decide to change the toolchain without even wondering about consequences (that's the outside impression, at least).

Now if we can get a list of commands to run server side for those modules, that's fine. Someone has to figure it out, though. And hopefully this will not be another set of commands for each module!

But for me, running autogen.sh is not acceptable. Then, DL is not mine, and if anyone wants to take maintainership and try another strategy, that would be fine, really.

I agree that some maintainers have been irresponsible, but I'll leave it for now.

Yes, running autogen.sh would be horrible. Thankfully, <https://git.gnome.org/browse/gtk+/tree/make-pot> allows us to make a .pot file without autogen.sh. GTK+ uses it now with "[ -e ../make-pot ] && (cd .. && ./make-pot) || intltool-update -g gtk+ -p" set on damned-lies.

What I'm asking is having this script on the d-l server and running it on modules that don't use intltool anymore, instead of copy-pasting it to every git repository.

That GTK make-pot script is a good starting point, indeed. I guess now the question is about xgettext flags to use, notably the --flag options. Are they all valid for all modules, or should they differ per-module?

Are we dropping the intltool capability of finding missing files in POTFILES.in?

(In reply to Claude Paroz from comment #7)
> That GTK make-pot script is a good starting point, indeed. I guess now the
> question is about xgettext flags to use, notably the --flag options. Are
> they all valid for all modules, or should they differ per-module?

I don't know. So far they seem to differ:

https://git.gnome.org/browse/zenity/tree/po/Makevars#n10

https://git.gnome.org/browse/giggle/tree/po/Makevars#n10

https://git.gnome.org/browse/gnome-flashback/tree/po/Makevars#n10

GTK+ itself seems to be the most elaborate.

> Are we dropping the intltool capability of finding missing files in
> POTFILES.in?

Unfortunately, xgettext can't do that. :(

https://git.gnome.org/browse/damned-lies/commit/?id=47600623ff396a3a6b78b33e81b4f3b9d294f5dc adds support for pure xgettext extraction.

I tried to automatically detect intltool usage, but I couldn't find a trustworthy method. Therefore, such modules should set '<gettext>' in their pot_method field.

Then I also had to add the ability to set different po domains per branch. (branch_from and branch_to fields for domains).

We'll have to convert some other modules than zenity (my test module) and we'll see how it goes...

Also note that with xgettext, the source paths in po files are now relative to the root path, not to the /po. I didn't find a way to keep the "relative-to-po-directory" paths.

This is amazing! Thank you so much for your work.

I tried to set up another module, but I can't find the pot_method field in the admin interface.

On the module page, down to the Domains section, under "Advanced" section which is hidden by default.

Oh, I see it now.

I converted gnome-flashback and there are two problems:

https://l10n.gnome.org/module/gnome-flashback/ - languages are duplicated

https://l10n.gnome.org/POT/gnome-flashback.master/gnome-flashback.master.pl.po - strings with context (msgctxt) are not extracted, for example this one:

#: gnome-flashback/libsound-applet/gvc-channel-bar.c:540
msgctxt "volume"
msgid "Unamplified"
msgstr "Bez wzmocnienia"

Could it be because https://git.gnome.org/browse/gnome-flashback/tree/po/Makevars#n53 is set to "no"?

The missing context is due to a missing XGETTEXT_OPTIONS in Makevars: --keyword=C_:1c,2

For the duplicate language issue, I'll investigate.

The duplicate language issue should be now fixed.

gettext 0.19.7 has new functionality:
"xgettext can now load custom string extraction rules supplied by consumer projects. The rules are written in XML, utilizing the Internationalization Tag Set (ITS) standard. All the existing XML-based language scanners (Glade, GSettings, and AppData) are rewritten using ITS. In addition, msgfmt now has --xml option to merge translations back to the original XML document."

its files are already provided by at least two modules:
https://git.gnome.org/browse/glib/commit/?id=50645b724a3b43767fd57e4af53365d0cd270382
https://git.gnome.org/browse/gtk+/commit/?id=f9e6ccd59256ef86bdfa3bfe9810df35f7ee00fe

I want port metacity to upstream gettext and to do that I will need to use ITS files to translate few .xml files. In my case ITS files probably will be provided from other module...

xgettext reads its files from GETTEXTDATADIR/its (/usr/share/gettext/its).

Will Damned-lies be able to handle this?

Thanks Alberts for sharing this interesting news. I would suggest to open two new bug reports: one for upgrading gettext from 0.19.6 to 0.19.7 on the Damned-Lies servers (against sysadmin product), and a second one (depending on the former) to adapt Damned-Lies to this new functionality.

https://bugzilla.gnome.org/show_bug.cgi?id=761992 for the gettext upgrade.

Now gettext is upgraded, any news for supporting its files?

That should work now, can you check?

I think it works - now mutter includes also xml translations that was missing before I added previous comment.

The commit adding ITS support is https://git.gnome.org/browse/damned-lies/commit/?id=bf56f5c84690cd336bcb4f5321d0e82f841ac73a