Do you have a module (not too complex if possible) with which we could experiment?

Hmm. There is simple-scan, for which I restored po/Makevars to keep it working with damned-lies: https://git.gnome.org/browse/simple-scan/commit/?id=e9ce6d6f31a60a22ac495ca56bd9034b36d44224

However, its po/meson.build is slightly different than the usual one-liner “i18n.gettext(meson.project_name(), preset: 'glib')” (e.g., epiphany).

I don't see any lang stuff in po/meson.build. Does it default to all languages in this case?

Also, the language list can be stored in any variable name. We can suppose that langs and languages will be very common, but can we count on that? It might also be a bit difficult to honor the specific indentation of the list. Is that important?

Looking at histories of:

https://github.com/mesonbuild/meson/blob/master/mesonbuild/modules/i18n.py

https://github.com/mesonbuild/meson/blob/master/mesonbuild/scripts/gettext.py

I think it reads from po/LINGUAS.

Oh, great, that would simplify things for us.
Can you sum up what is currently required on DL side to support Meson?

(For completeness, docs seem to be handled by https://github.com/mesonbuild/meson/blob/master/mesonbuild/scripts/yelphelper.py)

I can’t answer your questions. I’ll ask around for help.

So I'm not entirely sure of DL's needs but regarding the list of languages here is what Meson currently supports:

- For yelp you define languages directly as a keyword.
- For gettext you can either define languages directly or create a LINGUAS file.

So the question then is how to easily extract it and modify these. There is an experimental tool provided by meson that can modify build scripts[1] but it will have to be expanded for this. There is no tool to easily extract variables from build files though and using regex like you appear to on Makefiles is probably not the best idea but should be equally possible.

The gettext support is also still actively changing[2] and use of LINGUAS will probably be something phased out in favor of keeping things in the build files. If it is deemed the best solution though we can keep it around though.

For ideal integration this will surely require upstream changes.

[1] https://github.com/mesonbuild/meson/blob/master/mesonrewriter.py
[2] https://github.com/mesonbuild/meson/pull/1757

Keeping the LINGUAS file for the language list would be the safer for us currently. I suspect it will be very brittle to try modifying a build script, as you mentioned.
If you can suggest another safe method, we are open to other solutions.

Cool, wasn't aware of that. Thanks for fixing things!

Oops, sorry for the bugzilla spam and unexpected resolution. Typo'd the wrong bug in git-bz for bug 783370.

We have our fist modules with no intltool and no po/Makevars — totem, totem-pl-parser and nautilus-sendto:

https://bugzilla.gnome.org/show_bug.cgi?id=784137#c3

https://git.gnome.org/browse/totem/commit/?id=a13d42100ab3337de5050e82da81577c46cc6a64

For now, I'm still stuck until I found a correct way of parsing/interpreting meson.build files to extract languages, files, etc. Any suggestion welcome!

Although they are both still using Autotools, devhelp[0] and gnome-todo[1] don't use neither intltool nor po/Makevars (just in case they could help as references with meson support).

If you need any help, don't hesitate to contact me.

[0] https://git.gnome.org/browse/devhelp/log/?h=wip/meson
[1] https://git.gnome.org/browse/gnome-todo/commit/?id=407e7293fc191642788f8812488505b80850c6ff

Regarding Yelp, isn't the list of directories enough? For example: https://git.gnome.org/browse/totem/tree/help?id=a13d42100ab3337de5050e82da81577c46cc6a64

Oh right you'll still want the exact sources list..

(In reply to Iñigo Martínez from comment #14)
> Although they are both still using Autotools, devhelp[0] and gnome-todo[1]
> don't use neither intltool nor po/Makevars (just in case they could help as
> references with meson support).

Thanks. But actually, there is only a problem if DL needs to access variables defined inside meson.build. Currently, this might be a language list or a source file list for help documents. AFAICS this is not an issue with devhelp/ gnome-todo as they have LINGUAS files for UI translations, and no docs translations configured in DL.

Although I have read the whole bug, I still don't have an exact idea of what DL might need from meson, so the following may be totally wrong. I'm sorry if it actually doesn't apply, I'm just trying to be helpful.

devhelp / gnome-todo are using the 'LINGUAS' file which is required for autotools, but as Patrick has stated before[0], you can specify the language list for gettext[1], that should make the 'LINGUAS' file unnecessary. The ‘glib’ preset[2] uses default keywords used by glib, however the args option, which I still haven't used, may help adding extra keywords for custom needs[3].

gnome’s yelp function also has a language option[4] which replaces the 'HELP_LINGUAS' variable, and the same variable could be shared between gettext and yelp functions.

Finally, if you want to export the languages variable to DL, you can generate a configuration file by using configure_file[5]. It does generates a C/C++ header file by default, that AFAIK DL being Django-Python, is not that useful, but you also can specify an input template file where tokens will be replaced with varibles in config data[6], on a file compatible with Python.

Let’s see an example:

  languages = [‘en’, ‘fr’, ‘es’]

  # gettext with languages option making the LINGUAS file unnecessary.
  # preset ‘glib’ makes the Makevars file unnecessary.
  i18n.gettext(devhelp_name, languages: languages, preset: 'glib')

  # yelp with languages option used as HELP_LINGUAS replacement
  gnome.yelp(
    ‘damned-lies’,
    sources: sources,
    media: media,
    symlink_media: true,
    languages: languages
  )

  conf = configuration_data()
  # we will set languages array as an string with ‘ ‘ as the separator
  conf.set_quoted(‘LANGUAGES’, ‘ ‘.join(languages)
  # we will export the data in config by using config.py.meson file as a template
  configure_file(
    input: ‘config.py.meson’
    output: ‘config.py’,
    configuration: conf
  )

Then by importing ‘config.py’ you could access ‘LANGUAGES’ variable.

I hope this to be useful.

[0] https://bugzilla.gnome.org/show_bug.cgi?id=783099#c8
[1] http://mesonbuild.com/i18n-module.html#i18ngettext
[2] https://github.com/mesonbuild/meson/blob/master/mesonbuild/modules/i18n.py#L25
[3] https://bugzilla.gnome.org/show_bug.cgi?id=783099#c2
[4] http://mesonbuild.com/Gnome-module.html#gnomeyelp
[5] http://mesonbuild.com/Reference-manual.html#configure_file
[6] http://mesonbuild.com/Configuration.html#configuration

Thanks for the suggestion. It is interesting, but the main drawback is that you put the burden of the DL compatibility on module maintainers.
I'll come soon with a patch for basic Meson support, we'll see how it goes.

I added basic support for Meson by some magic (see https://git.gnome.org/browse/damned-lies/commit/?id=a7fd748ee732ec6b2c9eabace114dfaea1920ded for details).

I tried to make meson.build Python readable. I'm sure I'll make some of you cry loud...

It seems to work fine, except for these two modules:

https://l10n.gnome.org/module/polari/

https://l10n.gnome.org/module/pitivi/

Also, while not using Meson, https://l10n.gnome.org/module/meld/ is malfunctioning, but it has no help/Makefile??

Is there any reason pitivi doesn't use the gnome.yelp meson helper?

I don’t know (it doesn’t use the glib preset for UI translations either), but I’m not really willing to delve into their Phabricator thing.

(In reply to Claude Paroz from comment #22)
> Is there any reason pitivi doesn't use the gnome.yelp meson helper?

Probably because its build files were written before the gnome.yelp helper was written. If you poke the maintainers, they will fix it.

Today’s commits by Claude (https://git.gnome.org/browse/damned-lies/commit/?id=d502f1b306cf7c01315ecfabee804068c24fde8b and https://git.gnome.org/browse/damned-lies/commit/?id=2af1fe383135584203b94f217fce6eda4cecbf6e) fixed nautilus-sendto and gnome-bluetooth.


totem-pl-parser can’t generate a new .pot file and shows this error:

“Error regenerating POT file for totem-pl-parser:

xgettext --files-from POTFILES.in --directory /var/www/gnomeweb/scratchdir/git/totem-pl-parser --from-code utf-8 --add-comments --output totem-pl-parser.pot --msgid-bugs-address https://bugzilla.gnome.org/enter_bug.cgi?product=totem-pl-parser&keywords=I18N+L10N&component=General”


And totem itself uses Meson only to translate AppData, and intltool for the rest (see https://git.gnome.org/browse/totem/commit/?id=a13d42100ab3337de5050e82da81577c46cc6a64 and bug #783316).

I also tried removing po/Makevars from modules ported to Meson that kept it for d-l compatibility. Epiphany works perfectly, but frogr, with a slightly different-looking po/meson.build, does not.

Some Meson-based modules have started using a separate LINGUAS file for help:

https://git.gnome.org/browse/bijiben/commit/help?id=abb95c75bb3941ee45558400df8f0924336e735d

https://git.gnome.org/browse/eog/commit/help?id=b55f66560e6eff902b08346198ceb15b5500aed3

https://git.gnome.org/browse/epiphany/commit/?id=22c8ce87d4358cc811c8c680892935f71bbbed25

https://git.gnome.org/browse/file-roller/commit/help?id=80ce23d399e3911cc44447ca2e13e60b4356c14a

https://gitlab.gnome.org/GNOME/polari/commit/ac99737a5503f7d3f1bb2cd517e10df9af963c9c

LINGUAS files are now also supported for docs in D-L.

Piotr, should we keep this report open, or can we close it and open new ones when we find other incompatibilities?

Whatever works best for you!

OK, then please open new bugs if appropriate.