SquirrelMail / Internationalization / #15 use short locale names when possible

Tomas Kuliavas - 2005-03-09

Logged In: YES
user_id=225877

Reply
-------------------------------------------
Arabic uses only 'ar', because we can't select country. This
language is spoken in many countries. You can't use it as
argument, because people need 'ar' system locale in order to
use Arabic translation.

Historical background on use of xx_XX locale names in
squirrelmail.

From v.1.2.2 squirrelmail uses full locale + country name.
This was done in order to solve issues on some php with
gettext installs.

It is possible that issue was related to the fact that
squirrelmail used translation array key as locale name in
setlocale and putenv calls.

From SquirrelMail v.1.4.3 and 1.5.0 setlocale call does not
depend on translation array keys and uses full locale name
in most cases. Maybe you can find C programmer that would
prove that php gettext extension tries to fall back to
iso639 locale name when following php script is executed:
----
setlocale(LC_ALL,'lt_LT.UTF-8');
putenv('LC_ALL=lt_LT.UTF-8');
bindtextdomain('test','./locale');
textdomain('test');
echo _("Test");
----

We need confirmation that it acts the same on any php
version from 4.0.6, that php developers won't change such
behaviour and that there are no hidden "features" in some
OSes. Following naming standards might justify use of
different names in stable squirrelmail version, but we use
software repository that does not support renaming of the
files and such change might take some time.

strace on php 4.3.10 Linux Debian Sarge shows
----
open("/path/locale/lt_LT.UTF-8/LC_MESSAGES/test.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/path/locale/lt_LT.utf8/LC_MESSAGES/test.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/path/locale/lt_LT/LC_MESSAGES/test.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/path/locale/lt.UTF-8/LC_MESSAGES/test.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/path/locale/lt.utf8/LC_MESSAGES/test.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/path/locale/lt/LC_MESSAGES/test.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
----

currently I don't have installs of php 4.0.6 or other old
php versions with cli and can't test them.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tomas Kuliavas - 2005-03-09

Logged In: YES
user_id=225877

Reply by Christian Perrier <bubulle at debian dot org>
---------------------------
> "The language code should be used when naming and
installing po-files. This
> is not the same as the locale code. For Norwegian Bokml
the files should
> be named nb.po, but the locale (LANG) should be nb_NO."
>
> Unfortunately the document quoted above doesn't explain
why. Maybe the
> explanation is to be found in the RFCs and ISOs.

Well, probably not. This is a matter of anticipating the future.

Of course, in the case of Norwegian Bokml, as the only
locale using this language is nb_NO, there is no real issue
in naming file either nb_NO.po or nb.po.

But, just imagine that, for some yet unknown reason, a nb_FR
locale is developed because thousands of Norwegian people
come living in France just like the British people are
currently doing..:-)

Then, those people with set their locale as nb_FR but will
not benefit from nb_NO translations while they would if the
translation is bust "nb".

This case is indeed happening for the Catalan language.
There are software and Debian packages where the Catalan
translation is currently named "ca_ES" because the most
Catalan translators and speakers are in Spain. However, the
language is spoken in 3 countries (Spain, France and
Andorra) and locales are under work by Jordi Mallach for
these cases....

So, my usual recommendation is also using the ISO-639 code
alone with
very few exceptions:

-pt vs pt_BR as Brazilian Portuguese is indeed different
from Portuguese spoken in Portugal and former colonies

-zh_TW and zh_CN as common ways to distinguish between
Traditional and Simplified Chinese for the different ways to
*write* the Chinese language (regardless of distrinctions
about *spoken* languages : Mandarin or Cantonese for instance)

-pa_IN and pa_PK for Punjabi as used in India and Pakistan
for about the same reasons : Punjabi in India uses an
Indic-style script while Punjabi in pakistan uses an
Arabic-style script

I'm currently not aware of others cases where the use of the
country part in translations is technically useful.

I have no competence in the php specifics described by Tomas
Kuliavas and why this should urge the use of xx_YY
translation files, but I think that forcing the use of xx_YY
is simply impossible : there are too many languages spoken
in several countries (just count down the number of locales
for French, Spanish, Arabic, German....).

My understansing is thatsSoftwares should make corect use of
the LANGUAGE variable for choosing language alternatives.
For instance, a correct LANGUAGE variable for French in
France who also speaks Catalan
would be:

LANGUAGE="fr_FR:fr:ca_FR:ca:en"

which gives the order used for choosing translations by
gettext-compliant software. I guess that this should be
something like this for Norwegian people:

LANGUAGE="nb_NO:nb:no:nn:en"

assuming that all Norwegian people speak and understand some
Nynorsk
as you are forced to learn it at school...:-)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tomas Kuliavas - 2005-03-09

Logged In: YES
user_id=225877

We are willing to change it to short names. I think current
squirrelmail locale implementation allows it. But:

1. we have to test it and make sure that it works in
different OSes and php combinations.

2. we don't want to make radical changes in stable
squirrelmail version.

3. we can change only directory names used to store
translations. We can't accept environment variable changes
proposed by Christian, because they don't work in freebsd
and environment variables are only part of locale
implementation. I think glibc based systems don't depend on
environment variables.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tomas Kuliavas - 2006-10-09

assigned_to: tokul --> nobody
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

use short locale names when possible

Group

Searches

Help

#15 use short locale names when possible

Discussion