GNU gettext - Bugs: bug #53516, $LANGUAGE doesn't take...
You are not allowed to post comments on this tracker with your current authentication level.
bug #53516: $LANGUAGE doesn't take "en" into account
Submitter: | Maxime Buquet <ppjet> | ||
Submitted: | Thu 29 Mar 2018 05:50:56 PM UTC | ||
Category: | End-user / runtime | Severity: | 2 - Minor |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Thu 01 Jul 2021 02:52:04 PM UTC, comment #5: |
Mikko Rantalainen <mtrantalainen> |
Tue 29 Jun 2021 10:10:05 AM UTC, comment #4: en_US is ignored too.
|
d3coder |
Fri 30 Mar 2018 01:05:23 AM UTC, comment #3:
|
Gunnar Hjalmarsson <gunnarhj> |
Fri 30 Mar 2018 12:14:23 AM UTC, comment #2:
|
Maxime Buquet <ppjet> |
Thu 29 Mar 2018 06:29:56 PM UTC, comment #1: I think that en in the LANGUAGE list makes gettext look for en_US translations. Normally the en_US translation files are empty, though, since en_US is the default language, and then gettext goes to the next language in the list. So gettext behaves as it's expected to do.
|
Gunnar Hjalmarsson <gunnarhj> |
Thu 29 Mar 2018 05:50:56 PM UTC, original submission:
I am filling this following https://gitlab.gnome.org/GNOME/gnome-shell/issues/114.
|
Maxime Buquet <ppjet> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-09-15 | haible | Severity | 3 - Normal | 2 - Minor | |
2018-03-30 | haible | Category | None | End-user / runtime |
Powered by Savane 3.13-f8d8.
Corresponding source code
I agree. The source language (the msgid string) should be considered to be of language called "C", not English nor en_US. And it seems to be the current implementation, too!
However, most English speaking developers do not understand this difference and as a result we have technically missing English localizations for pretty much all software.
Now, the current setup is obviously very problematic for people that prefer english but know some other languages well, too. For example, my native language is Finnish but I know English well enough to prefer it for computer use. As you said, many applications have empty strings for English localization so you always get fallback to alternative language instead of getting the English when the original developers intent was that their "C" variant is the official English version.
Of course, the correct way would require that every developer that thinks their "C" version is the official English version, runs the command "msgen" for every release they do. However, as this is obviously not happening, you cannot configure your locale to prefer English and fallback to any other language.
This is not because gettext assumes that English is default but because English translation is nearly always completely missing and it therefore uses fallback to another language.
Perhaps there could be some kind of magic like environment variable
GETTEXT_ASSUME_EMPTY_EN_IS_COMPLETE_ENGLISH=1
which makes gettext pretend that if en.mo is missing or is full of empty strings (obviously, the msgid "" would still have metadata) then assume that "C" is the complete English translation instead of English translation missing all the strings. However, if the translation has even a single localized string assume that it's the best translation that the original developers were able to create and the intent is to fallback to another language for any missing strings.
This would allow applications that have real partial English localization to use partial English UI and fallback to user selected alternative language(s) for the rest of the strings (as originally designed for the LANGUAGE setting). However, lazy English speaking developers could continue doing half-assed job with their English / "C" localization and everything could still work more or less correctly for all languages.
It might be even sensible to make that default and request current behavior on such special environment flag only. However, it would make the current 3rd party developer assumption that "C" === "English" permanent forever.
Of course, an obvious optimization would be to skip such special logic if "en" is not part of environment variable LANGUAGE because that's the only commonly mis-used language with gettext.
However, in my opinion it's not okay to pretend that everything is fine as things stand now. The reality is that all those applications are technically missing all the localizations and the only way to use those applications in English is to fallback all the way to "C". I'm pretty sure that it wasn't the original developer intent. But that's the reality we have.