X-Moto

Tasklist

FS#770 - Translation files wrongly include country code

Attached to Project: X-Moto
Opened by Anonymous Submitter - Monday, 21 February 2011, 13:00 GMT
Task Type Bug Report
Category GUI
Status Unconfirmed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version svn
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Translation files specify the country code (e.g. ca_AD, ca_ES, ca_FR, ca_IT) even if that's counterproductive.

http://www.gnu.org/software/libc/manual/html_mono/libc.html#Using-gettextized-software explain that:


"If now the user set in her/his environment the variable LANGUAGE to de the gettext function will try to use the translations from the file

/usr/local/share/locale/de/LC_MESSAGES/test-package.mo

From the above descriptions it should be clear which component of this filename is determined by which source.

In the above example we assumed that the LANGUAGE environment variable to de. This might be an appropriate selection but what happens if the user wants to use LC_ALL because of the wider usability and here the required value is de_DE.ISO-8859-1? We already mentioned above that a situation like this is not infrequent. E.g., a person might prefer reading a dialect and if this is not available fall back on the standard language.

The gettext functions know about situations like this and can handle them gracefully. The functions recognize the format of the value of the environment variable. It can split the value is different pieces and by leaving out the only or the other part it can construct new values. This happens of course in a predictable way. To understand this one must know the format of the environment variable value. There is one more or less standardized form, originally from the X/Open specification:

language[_territory[.codeset]][@modifier]

Less specific locale names will be stripped of in the order of the following list:

1. codeset
2. normalized codeset
3. territory
4. modifier

The language field will never be dropped for obvious reasons."


So using only the language name ensures that it will work with any country code. But using "de_DE" it will not work with "de_AT".
All the country codes should be removed (but pt_BR, which is a valid dialect). And in the case of "ca" delete those ugly symlinks.
This task depends upon

Loading...