Build fails if no translation matching $LINGUAS

[cjmayo]

LINGUAS="en_GB" ./configure
...
make[2]: *** No rule to make target 'en_GB.po', needed by 'en_GB.gmo'.  Stop.

need a file po/LINGUAS

Used to exist and subsequently generated with waf: 85db7a3
but doesn't seem to have been replaced when waf removed.

[b4n]

What you see here is not a bug AFAIK, there just is no en_GB translation so if you ask for it it fails.

[cjmayo]

The example is a bit fake, you probably don't ask for it specifically for geany-plugins it is a global variable that is set anyway.

If the translation isn't there it isn't there. The user can't do anything to fix it. It's nice for them to know but halting the build seems a bit extreme.

The gettext manual has "The po/ directory should also receive a file named LINGUAS."
https://www.gnu.org/software/gettext/manual/html_node/po_002fLINGUAS.html

[b4n]

Why do you absolutely want this file? We do honor the LINGUAS variable you specify, and we set ALL_LINGUAS. We use AM_GLIB_GNU_GETTEXT which seems little different than plain AM_GNU_GETTEXT but well.

The question is why you want that file so badly, or rather, what behavior is a problem, what you expect, and why is it valid.

[b4n]

BTW, https://www.gnu.org/software/gettext/manual/gettext.html#Installers doesn't seem to suggets using en_GB to be valid.
Anyway, yes, maybe our handling of LINGUAS is wrong and it should only filter available languages rather than use it as a literal. But the Gettext documentation doesn't really tell, so well.

[cjmayo]

On po/LINGUAS, I was guessing a bit how this bit of po/Makefile.in.in worked:

ALL_LINGUAS = @ALL_LINGUAS@

PO_LINGUAS=$(shell if test -r $(srcdir)/LINGUAS; then grep -v "^\#" $(srcdir)/LINGUAS; else echo "$(ALL_LINGUAS)"; fi)

USER_LINGUAS=$(shell if test -n "$(LINGUAS)"; then LLINGUAS="$(LINGUAS)"; ALINGUAS="$(ALL_LINGUAS)"; for lang in $$LLINGUAS; do if test -n "`grep \^$$lang$$ $(srcdir)/LINGUAS 2>/dev/null`" -o -n "`echo $$ALINGUAS|tr ' ' '\n'|grep \^$$lang$$`"; then printf "$$lang "; fi; done; fi)

USE_LINGUAS=$(shell if test -n "$(USER_LINGUAS)" -o -n "$(LINGUAS)"; then LLINGUAS="$(USER_LINGUAS)"; else if test -n "$(PO_LINGUAS)"; then LLINGUAS="$(PO_LINGUAS)"; else LLINGUAS="$(ALL_LINGUAS)"; fi; fi; for lang in $$LLINGUAS; do printf "$$lang "; done)

POFILES=$(shell LINGUAS="$(PO_LINGUAS)"; for lang in $$LINGUAS; do printf "$$lang.po "; done)

DISTFILES = Makefile.in.in POTFILES.in $(POFILES)
EXTRA_DISTFILES = ChangeLog POTFILES.skip Makevars LINGUAS

POTFILES = \
# This comment gets stripped out

CATALOGS=$(shell LINGUAS="$(USE_LINGUAS)"; for lang in $$LINGUAS; do printf "$$lang.gmo "; done)

I thought I'd tested it but apparently not.

Instead I think the answer is to set ALL_LINGUAS to the available translations, not the value of the user's LINGUAS.
e.g.:
https://www.redhat.com/archives/libvir-list/2008-April/msg00094.html
https://pidgin.im/pipermail/commits/2015-March/025530.html

Pull request and test results here: #477

On expected behaviour:

After a transition time for packages to be converted, the LINGUAS
environment variable will maintain the standard gettext behaviour and
will work as expected with all package managers. It controls which
language translations are built and installed. An unset value means all
available, an empty value means none, and a value can be an unordered
list of gettext language codes, with or without country codes. Usually
two letter language codes suffice, but can be narrowed down by country
codes with a "ll_CC" formatting, where "ll" is the language code and
"CC" is the country code, e.g., "en_GB".
https://www.gentoo.org/support/news-items/2016-06-23-l10n-use_expand.html

(PR doesn't quite do that empty value installs all, but I can live with that)

and:

Unless translations are disabled, all those available are installed together with the package. However, the environment variable LINGUAS may be set, prior to configuration, to limit the installed set.
https://www.gnu.org/software/gettext/manual/html_node/Installers.html#Installers

There is already pt_BR and zh_CN available, so I don't see en_GB as exceptional.