1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#266226: locales: @euro support should again be supported for _all_

    From Frans Pop@1:229/2 to All on Tue Aug 17 06:10:07 2004
    XPost: linux.debian.maint.boot
    From: [email protected]

    Package: debian-installer
    Severity: important

    NOTE: I strongly feel this should be fixed before RC2 is released.

    HISTORY
    =======
    With the introduction of the new languagechooser, support for @euro locales
    was lost for a lot of countries which had that support before.
    This was noted at the time [1], but ignored because the relevance was unclear.

    Now it looks as if proper @euro support _should_ be present [2].

    [1] http://lists.debian.org/debian-boot/2004/06/msg01818.html
    [2] http://lists.debian.org/debian-boot/2004/08/msg01145.html

    PROBLEM
    =======
    Currently only a few locales have proper @euro support. For these it is set in the 3rd field in languagelist in languagechooser, but this solution does not work for all relevant language/country combinations.

    In languagelist only primary language/country combinations (e.g. French - fr_FR@euro, Spanish - es_ES@euro, Catalan - ca_ES@euro) are present, but not secondary combinations (e.g. French in Belgium - fr_BE, German in Austria - ge_AT).
    Currently not even all of the primary combinations have @euro support in languagelist (e.g. Dutch - nl_NL, Danish - da_DK).

    The current code in the postinst for countrychooser that keeps a suffix if any is present in the 3rd field of languagelist could provide a solution for some situations, but not for all [a] and even leads to undesired results in other situations [b].

    [a] English (en_US) does not have a @euro suffix, but en_IR needs one
    [b] AFAICT French in Canada would currently 'inherrit' a @euro suffix
    from fr_FR@euro, but because fr_CA@euro is unsupported the locale
    will fall back to fr_FR@euro even though a fr_CA locale does exist

    SOLUTION
    ========
    I think the solution would be to include code (probably in postinst for countrychooser).
    This script should roughly check whether the previously generated locale concerns an euro country, adds the @euro suffix and checks to see if the new locale is supported. There would have to be some exceptions e.g. for combinations that prefer UTF8 encoding.

    Another (maybe the best in the long run) solution could be remove suffixes
    from the languagelist altogether and to have a table in countrychooser of preferred locales for any xx_YY combinations where a suffix (or another
    locale than can be automatically generated from the selected language and country) is wanted.

    The relevant countrycodes for euro are: AT BE DE FI FR GR IR IT LU NL PT SP.


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Christian Perrier@1:229/2 to All on Tue Aug 17 09:20:04 2004
    XPost: linux.debian.maint.boot
    From: [email protected]

    reassign 266226 languagechooser
    thanks

    SOLUTION
    ========
    I think the solution would be to include code (probably in postinst for countrychooser).

    I'm already trying to hack this postinst for having it deal properly
    with the Norwegian case (they want to keep no_NO as locale while the
    built locale is nb_NO). This is 260873, which indeed pertains to countrychooser.


    This script should roughly check whether the previously generated locale concerns an euro country, adds the @euro suffix and checks to see if the new locale is supported. There would have to be some exceptions e.g. for combinations that prefer UTF8 encoding.

    Another (maybe the best in the long run) solution could be remove suffixes from the languagelist altogether and to have a table in countrychooser of preferred locales for any xx_YY combinations where a suffix (or another locale than can be automatically generated from the selected language and country) is wanted.

    The relevant countrycodes for euro are: AT BE DE FI FR GR IR IT LU NL PT SP.


    This bug report rejoins another BR we have (263317) for which Recai
    provided a patch (I just discover it).

    I have applied 263317 patch which should also make half of the work
    for your suggestion. This patch looks into SUPPORTED locales whether
    the combination with the modifier inherited from languagechooser is
    valid. If it isn't, a locale without the modifier is chosen.


    The other part is adding the @euro modifier for all languages which
    have a Euro country as primary country.

    Maintaining a table in countrychooser for the special @euro case is
    not really satisfactory for me. I'd prefer adding a medium priority
    question about modifiers when there are different modifiers
    possibilities for a given locale:

    -at the end of countrychooser we have xx_YY as LOCALE
    -we grep SUPPORTED for all supported locales with this
    -if there are two or more of these, we prompt (medium prio) about the
    one to choose, defaulting to the one with the modifier




    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Frans Pop@1:229/2 to Christian Perrier on Tue Aug 17 21:10:07 2004
    XPost: linux.debian.maint.boot
    From: [email protected]

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hello Christian,

    First of all, I'm very happy that you've started work on this. I was thinking of giving this a go myself.

    I think your proposal should work, so please go ahead if you prefer that.
    I'd just like to add some of my thoughts.

    On Tuesday 17 August 2004 08:58, Christian Perrier wrote:
    Maintaining a table in countrychooser for the special @euro case is
    not really satisfactory for me. I'd prefer adding a medium priority
    question about modifiers when there are different modifiers
    possibilities for a given locale:

    -at the end of countrychooser we have xx_YY as LOCALE
    -we grep SUPPORTED for all supported locales with this
    -if there are two or more of these, we prompt (medium prio) about the
    one to choose, defaulting to the one with the modifier

    The downside for this is that this would probably result in a prompt for most locales as most have a "standard" locale and an UTF variant.
    Personally I don't mind this (as you say: at medium or low priority).

    Two remarks:
    - - IMHO it's very important to get the default right; taking a default
    modifier from languagelist has obvious limitations.
    For instance, suppose that an English speaking country YY would like
    their default to be en_YY.UTF8. As en_US does not have the .UTF8 modifier,
    this would be difficult in your proposal.
    - - Using ALL supported locales to generate the list for the dialog means we
    will also offer the deprecated nl_NL and fr_FR locales for new
    installations.

    That's what gave me the idea of putting the defaults in a separate table as maybe the most flexible solution for the long run (and not only for @euro,
    but for all special wishes regarding locales, see below).
    Of course the downside is that you still have to provide defaults for combinations not in the table and that you'll have to maintain the table.

    Being able to offer a choice of locales is something I thought of as well. This could be implemented as wellif we were to use a table:

    Example of a table (1st value in 2nd field is default):
    cy_GB:cy_GB.UTF-8 # only one option, so no choice en_US:en_US|en_US.UTF8
    fr_FR:fr_FR@euro|fr_FR.UTF8 # omitting the deprecated fr_FR fr_CA:fr_CA|fr_CA.UTF8
    jp_JP:ja_JP.EUC-JP|ja_JP.UTF-8
    #
    # For the Netherlands I'd personally like to see:
    nl_NL:nl_NL@euro|nl_NL.UTF8
    en_NL:en_US|en_US.ISO-8859-15|en_US.UTF8

    If I can help by reviewing/testing your changes, please let me know.

    Cheers,
    FJP
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFBIlLQgm/Kwh6ICoQRAmBNAKDTuisYIddE6vJfCYgNf8Ryj3cCzACcDdgV HdoFyj53uoaWyGNODfgOqBs=
    =rR36
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)