bugGNU 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
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Thu 01 Jul 2021 02:52:04 PM UTC, comment #5: 

> [comment #2:]
> > To put it in another way, it makes no sense to have en before any other language in the LANGUAGE priority list. Ever.


> [comment #4:]
> This is valid when en_US is the default language, which I give you is probably true in 99% of the cases. I don't object to it being the default, I just don't want to assume.


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.

Mikko Rantalainen <mtrantalainen>
Tue 29 Jun 2021 10:10:05 AM UTC, comment #4: 

en_US is ignored too.

echo $LANGUAGE
de:en_US:ru

App doesn't have DE translation
App has EN and RU translations.
It displays RU translation

I tried de:en:ru, but it still displays in russian.

d3coder
Fri 30 Mar 2018 01:05:23 AM UTC, comment #3: 

> Does that seem reasonable?


Yes. I have to admit that I didn't take into account the possibility of alternative default languages. The presence of those will/would require a new way to think about the fallback language feature (which is what the LANGUAGE variable is all about).

Gunnar Hjalmarsson <gunnarhj>
Fri 30 Mar 2018 12:14:23 AM UTC, comment #2: 

> To put it in another way, it makes no sense to have en before any other language in the LANGUAGE priority list. Ever. If you want the display language to be English, which is always present, why making use of LANGUAGE at all?


This is valid when en_US is the default language, which I give you is probably true in 99% of the cases. I don't object to it being the default, I just don't want to assume. Maybe some projects would like to change the default for whatever reasons, and in this case it would be nice to be able to declare it, with that being set to en_US as default (no need for other projects to call it).

Does that seem reasonable?

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.

To put it in another way, it makes no sense to have en before any other language in the LANGUAGE priority list. Ever. If you want the display language to be English, which is always present, why making use of LANGUAGE at all?

As a side note, you should really not set LC_ALL on a GNOME desktop. If you do, you won't be able to control language or formats via the Region & Language GUI.

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.

I wanted to try out $LANGUAGE, here is what I have in /etc/locale.conf:
LANG=en_GB.UTF-8
LC_ALL=en_GB.UTF-8
LANGUAGE=en:fr:ja

(Note the man says LC_ALL may not be configured in this file, but it's not the point here).

I get applications displaying text in "en", "fr", and "ja", whereas I would only get "en" without $LANGUAGE set.

This doesn't only apply to GNOME software, but most projects using gettext out there I have used.

Please tell me if this analysis is wrong: I believe projects often use english as their default language, and when $LANGUAGE is set, gettext will look for available translations in the order declared, won't find any for english, then look for other languages, and then fallback on msgid if nothing is found.

What could be done to fix this is to ask projects to use actual translations for english (having an en.po), or a better solution might be to allow them to declare that msgid is actually a language, and what language it is, (setting "en" as default probably?).

Maxime Buquet <ppjet>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtrantalainen (Posted a comment)
  • -email is unavailable- added by d3coder (Posted a comment)
  • -email is unavailable- added by haible (Updated the item)
  • -email is unavailable- added by gunnarhj (Posted a comment)
  • -email is unavailable- added by ppjet (Submitted the item)
  •  

    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.

    Only logged-in users can vote.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-15 haible Severity3 - Normal 2 - Minor
    2018-03-30 haible CategoryNone End-user / runtime

    Back to the top


    Powered by Savane 3.9