#15 use short locale names when possible

open
nobody
None
5
2006-10-09
2005-03-09
No

Adding this in order to have some bug tracker instead
of discussion on mailing lists.

Email from mailing list
--------------------------------------------
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

----------------------------------------

Discussion

  • Tomas Kuliavas

    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.

     
  • Tomas Kuliavas

    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...:-)

     
  • Tomas Kuliavas

    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.

     
  • Tomas Kuliavas

    Tomas Kuliavas - 2006-10-09
    • assigned_to: tokul --> nobody
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks