...

Please change the directory name of the directory used to store the Norwegian Bokmål translation from nb_NO to nb. This will make it consistent with the other packages translated to Norwegian Bokmål, and ease the work of the Norwegian translators.

Now the translation files are stored in locale/nb_NO/LC_MESSAGES/squirrelmail.{mo|po}, but in the future they should be stored in locale/nb/LC_MESSAGES/squirrelmail.{mo|po}.

As you can see from the links below most translations store their messages in nb, and only a select few use nb_NO.

http://www.debian.org/international/l10n/po/nb http://www.debian.org/international/l10n/po/nb_NO

I see you already do this with the language code 'ar', so this shouldn't be much of a problem.

Altough I'm not the maintainer of Norwegian Nynorsk (nn_NO), I know they've asked for the same fix. As you can see, the same "problem" is located there too.

http://www.debian.org/international/l10n/po/nn http://www.debian.org/international/l10n/po/nn_NO

CC to i18n-no@ since the request came from them. Please keep them included in the conversation.

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.

I think I've asked Fredrik and Ola to forward similar email to Norwegian i18n mailing list. --

Tomas

Regarding Nynorsk I replied to all, which in this case was Ola only. I don't know if he forwarded it to i18n-no@lister.ping.uio.no or not. I haven't heard from him since (2005-02-25).

I'm not sure I understand why using "nb_NO" and "nn_NO" instead of "nb" and "nn" is an issue, but on the other hand I don't have much experience l10n and i18n. If Bokmål, however unlikely, were to be spoken anywhere else, and they changed parts of it for whatever reason, the country code is needed to indicate this, right? Wouldn't it make more sense to use the language code and the country code instead of just the language code when it's possible? Or do you want to keep the translations flexible if Bokmål should appear anywhere else in the world? Wouldn't the use of just the language code present a problem for languages spoken and written differently in different countries like Sami (se_NO, se_SE, se_FI) or Swedish (sv_SE, sv_FI)?

I skimmed RFC 3066 and found section 2.3 point 1 which states: "use the most precise tagging known to the sender that can be ascertained and is useful within the application context". Doesn't this suggest that the country code should be used when possible?

http://i18n.skolelinux.no/localekoder.txt states (quick translation from Norwegian by myself):

"The language code should be used when naming and installing po-files. This is not the same as the locale code. For Norwegian Bokmål 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.

These may be silly questions and I may display lack of knowledge, but as I wrote: I'm still a novice. I don't know the RFCs and ISOs by heart and understand them in every detail, so feel free to enlighten me. I'm not a i18n-no@lister.ping.uio.no subscriber, so answers must be sent to squirrelmail-i18n@lists.sourceforge.net or my personal address sqm_admin@fimbul.net.

For a technical background regarding SquirrelMail's solution read Tomas' reply (also quoted above in this mail). In my opinion, he knows more about langugaes, SquirrelMail and the combination thereof than I do.

Sincerely, Fredrik.

...

"The language code should be used when naming and installing po-files. This is not the same as the locale code. For Norwegian Bokmål 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 Bokmål, 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...:-)

See https://sourceforge.net/tracker/index.php?func=detail&aid=1159695&gr...

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 it.

I suggest using SourceForge tracker for discussion about the problem. It is possible that problem will be solved in squirrelmail 1.6.