Re: [SM-I18N] Changes to Norwegian =?utf-8?Q?Bokm=C3=A5l_?=(again)

[Tomas K. <to...@us...>]

> 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