'meson setup' with i18n module requires initial .po files

[ferdnyc]

Describe the bug Following along with the Localisation doc and setting up a simple project, I found that meson setup wouldn't even successfully generate a builddir until I created an empty .po file for each language listed in po/LINGUAS.

There are two issues with this, IMHO:

1. It just seems silly and a bit tedious
2. Worse, it's mentioned nowhere in the Localisation doc or the i18n module reference. In fact, the former implies quite the opposite, ending with:

generate .po files

For each language listed in the array above we need a corresponding .po file. Those can be generated by running the following command from your build folder.

$ meson compile intltest-update-po

You can't run a command in your build folder if meson hasn't even successfully created it.

To Reproduce hello.cpp:

#include <iostream>
int main() {
	std::cout << _("Hello world.") << '\n';
}

meson.build (largely generated by meson init):

project('hello', 'cpp',
  version : '0.1',
  default_options : ['warning_level=3', 'cpp_std=c++14'])

executable('hellp',
           'hello.cpp',
           install : true)

subdir('po')

po/meson.build:

i18n = import('i18n')
add_project_arguments(
  '-DGETTEXT_PACKAGE="' + meson.project_name() + '"',
  language: 'c',
)
i18n.gettext(meson.project_name(), preset: 'glib')

po/LINGUAS: es fr de po/POTFILES: hello.cpp

Run meson with this structure, and it will fail due to missing .po files:

$ meson setup build .
The Meson build system
Version: 1.2.1
Source dir: /var/tmp/hello
Build dir: /var/tmp/hello/build
Build type: native build
Project name: hello
Project version: 0.1
C++ compiler for the host machine: ccache c++ (gcc 13.2.1 "c++ (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1)")
C++ linker for the host machine: c++ ld.bfd 2.39-9
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program msgfmt found: YES (/usr/bin/msgfmt)
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge found: YES (/usr/bin/msgmerge)
Program xgettext found: YES (/usr/bin/xgettext)

po/meson.build:6:5: ERROR: File es.po does not exist.

A full log can be found at /var/tmp/hello/build/meson-logs/meson-log.txt

Run touch po/{es,fr,de}.po, and meson now succeeds.

Expected behavior Meson sets up a build system that can generate .po files, the same way it will generate a .pot file after running meson compile hello-pot

system parameters

• Is this a cross build or just a plain native build (for the same computer)?
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)
• what Python version are you using e.g. 3.8.0
• what meson --version
• what ninja --version if it's a Ninja build

$ cat /etc/system-release
Fedora release 38 (Thirty Eight)

$ python --version
Python 3.11.5

$ meson --version
1.2.1

[aullidolunar]

Any solution for this one? Here with meson 1.5.1

[ferdnyc]

@aullidolunar

Any solution for this one? Here with meson 1.5.1

The solution is to just create empty .po files in the source dir, before running meson setup for the first time. It's a bit annoying, but it's a one-time thing. (One time per project, I mean.) Once the builddir is created, meson compile <project>-update-po will populate the empty files from the .pot file generated by meson compile <project>-pot. Then you can check those updated .po files into version control.

[ferdnyc]

(You can quickly create all of the necessary files with this shell one-liner:)

cat po/LINGUAS | while read _l; do touch po/${_l}.po; done

[ferdnyc]

Looks like #9074 is where this got broken, the PR had good intentions but made the existence of .po files a new prerequisite for setting up the build system.

[aullidolunar]

OK. A external script will do.

[rautyrauty]

Meson maintainers, please fix the bug or accept PR!

[dcbaker]

I think this is related to: https://github.com/mesonbuild/meson/issues/15053

[eli-schwartz]

Meson maintainers, please fix the bug

I took a stab at this once but got stuck on some details and wasn't sure how to continue. It fell off my plate and because FOSS is FOSS and nobody pays me to fix things in my hobby time, I got distracted by other stuff that fixed things I was personally interested in. :D

or accept PR!

... but as for this, what is your reason to assume we are rejecting PRs to fix it? Are you aware of a PR which we should merge? Would you like to write such a PR?

[ferdnyc]

@eli-schwartz #13873 is the PR in question. (Which doesn't fix the issue, because I don't see how it can be fixed, but it does at least fix the documentation to not give wrong instructions on how to use the i18n module.)

[eli-schwartz]

@ferdnyc roughly speaking, adding languages to LINGUAS should not cause a reconfigure but instead wait for update-po to create the files (perhaps it should run a secondary command that checks if the .po files exist and triggers a reconfigure?) and update-po should either trigger reconfigure or, preferably, regenerate a subninja.

The internationalization support is very isolated and standalone, being able to regenerate it outside of a full meson setup --reconfigure would be quite interesting but might need a bit of the backend to be remodeled.