Translations under a language's main dialect are not found if LANGUAGE contains only the language code

A similar bug report to GNU is archived at http://lists.gnu.org/archive/html/bug-gnu-utils/2011-01/msg00010.html

You might want to submit it to their bug tracker as well, at http://savannah.gnu.org/bugs/?func=additem&group=gettext and then add a link to the upstream bug here (you might need to create a savannah account for that)

On the other hand, this works:

LANGUAGE=de gedit

And it launches gedit in German as expected.

Some more tests:

My installed languages are:
ls /usr/share/locale-langpack/
ar ca@valencia en en@boldquot en_GB en@quot en_US es
ca de en_AU en_CA en_NZ en@shaw en_US@piglatin zh_CN

$ LANGUAGE=ca gettext -d evince "All Files"
Tots els fitxers
=> Works as expected

$ LANGUAGE=es gettext -d evince "All Files"
Todos los archivos
=> Works as expected

$ LANGUAGE=de gettext -d evince "All Files"
Alle Dateien
=> Works as expected

Well, David, those examples just show that gettext normally works as expected, don't they? My intention with this bug is to point at the possible exception case when a translation of a text string is available e.g. under /usr/share/locale/es_ES but not under /usr/share/locale/es or /usr/share/locale-langpack/es. Then the string won't get translated if LANGUAGE is set to 'es', so I don't understand the significance of the above quote. I believe that either the code or the docs ought to be corrected.

Upstream bug report sent to a more specific email address:
http://lists.gnu.org/archive/html/bug-gnu-utils/2011-03/msg00014.html

Gunnar, I cannot reproduce this in lucid or precise. I think your test case is wrong. You either need to export the LANGUAGE variable or prepend the command with it. Please reconfirm that you see the same results as previously reported here with

$ LANGUAGE=de_DE gettext -d mytest myTestWord$'\n'
$ LANGUAGE=de gettext -d mytest myTestWord$'\n'

FWIW, in all cases I tested, the returned value was always the untranslated "myTestWord" string which does not seem right, either. But I'm not an expert with gettext at all.

Hi Rolf,

No, there is no need to export etc. if you just run a few commands like that; the temporary LANGUAGE value is inherited by processes started from the same terminal process. I take for granted that you realize that mytest.po was created before I run the commands shown in the bug description.

I just run this (somewhat cleaner) code in Oneiric, and this time the creation of mytest.po is included:

$ echo 'msgid "myTestWord"
> msgstr "meinTestWort"' > mytest.po
$ sudo mkdir -p /usr/share/locale/de_DE/LC_MESSAGES
$ sudo msgfmt mytest.po -o /usr/share/locale/de_DE/LC_MESSAGES/mytest.mo
$ LANGUAGE=de_DE
$ echo $( gettext -d mytest myTestWord )
meinTestWort
$ LANGUAGE=de
$ echo $( gettext -d mytest myTestWord )
myTestWord
$

So the behavior is still there, I'd say. If you can't reproduce that either, please feel free to post one of your test cases. Then I'll try to figure out what the cause may be.

I think it's quite obvious that the docs don't reflect the actual behavior, and I suggested a new wording at http://lists.gnu.org/archive/html/bug-gnu-utils/2011-03/msg00017.html. It would be good if you could help convincing upstream of it. :)

Gunnar, confirming your own tickets is very bad style, as is telling other volunteers what work they should do on your behalf. FWIW, your latest test case bails out for me at step 3.

$ sudo msgfmt mytest.po -o /usr/share/locale/de_DE/LC_MESSAGES/mytest.mo
mytest.po:1: missing `msgstr' section
mytest.po:2:2: syntax error
msgfmt: found 2 fatal errors

I have no real idea of how gettext works, but I'm not convinced you do, either ;-)

I'm outta here. Good luck.