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

Bug #700213 reported by Gunnar Hjalmarsson on 2011-01-08
4
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gettext
Undecided
auto-bug-gnu-gettext
gettext (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: gettext

gettext does not behave in accordance with this para in section 2.3.3
of the gettext docs:
   "In the `LANGUAGE' environment variable, but not in the other
environment variables, `LL_CC' combinations can be abbreviated as `LL'
to denote the language's main dialect. For example, `de' is equivalent
to `de_DE' (German as spoken in Germany), and `pt' to `pt_PT'
(Portuguese as spoken in Portugal) in this context."

This is how I reached that conclusion:

$ cat mytest.po
msgid "myTestWord\n"
msgstr "meinTestWort\n"
$ sudo msgfmt mytest.po -o /usr/share/locale/de_DE/LC_MESSAGES/mytest.mo
$ LANGUAGE=de_DE
$ gettext -d mytest myTestWord$'\n'
meinTestWort
$ LANGUAGE=de
$ gettext -d mytest myTestWord$'\n'
myTestWord
$

I would have expected the German translation also when LANGUAGE was set
to just 'de'.

Ubuntu release: Maverick 10.10
gettext version: 0.18.1.1-1ubuntu2

David Planella (dpm) wrote :

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)

David Planella (dpm) wrote :

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

Changed in gettext (Ubuntu):
status: New → Incomplete
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

Changed in gettext (Ubuntu):
status: Incomplete → New
Gunnar Hjalmarsson (gunnarhj) wrote :

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

Rolf Leggewie (r0lf) wrote :

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.

Changed in gettext (Ubuntu):
assignee: nobody → Rolf Leggewie (r0lf)
status: New → Incomplete
importance: Undecided → Medium
Gunnar Hjalmarsson (gunnarhj) wrote :

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. :)

Changed in gettext (Ubuntu):
status: Incomplete → Confirmed
Rolf Leggewie (r0lf) wrote :

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.

Changed in gettext (Ubuntu):
assignee: Rolf Leggewie (r0lf) → nobody
status: Confirmed → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

  • auto-bug-gnu-gettext Edit

Bug watches keep track of this bug in other bug trackers.