Language variants information missing in the language selection list

[David Planella]

Binary package hint: gdm

In the login screen of Karmic, the user has the possibility to choose a different language than the one defined as default.

Some language packs install language variants along with the main language, which can then be selected in that list of languages. Some examples of language variants: ca@valencia, sr@latin, etc.

The jaunty gdm version showed an indication of the variant in the list, in the form of "<translated language> (<variant information>)". In Karmic, the variant information is lost, showing the same two language choices in the list.

The attached screenshot shows this situation. In Jaunty, the two highlighted entries woould have been:

Català
Català (UTF-8@valencia)

[Sebastien Bacher (seb128)]

The issue seems fixed in the current version, could you try if that works better? There is no catalan entries there

[David Planella (dpm)]

Version 2.27.90-0ubuntu1 still presents the same problem. I've tested it both on Ubuntu and UNR Karmic.

It's exactly the same situation shown in the attachment on comment #1.

[Pau Iranzo (paugnu)]

Hi

Same problem here with ca@valencia. The option "Catalan (Spain)" appears twice, it seems that the first one is the standard and the second one the valencian variant (ca@valencia). It's kind of annoying...

[manutortosa (manutortosa)]

Same here two "Catalan (Spain) entries, simply changing the name of second one will be great.

[Josep (jvmonjo)]

same issue here with valencian variation of catalan language. I can't find ca@valencia

[carlesbiano (carlesbiano)]

Here I've got the same problem with ca@valencia, I hope it might not be difficult to solve it. Thanks!

[Sebastien Bacher (seb128)]

Unassigning from the Canonical Desktop Team since we don't work on those

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

Is this still an issue? Please re-confirm if it is.

[Pau Iranzo (paugnu)]

Hi,

With Karmic this changed and now the problem is other one. We should open a new bug I guess. So this one can be ruled out...

[Pau Iranzo (paugnu)]

Sorry, I meant: «On Lucid...»

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

Then, I'll mark this as Invalid.

[AsstZD (eskaer-spamsink)]

Still in Maverick.

[David Planella (dpm)]

The bug is present as reported in Karmic, Lucid, Maverick and Natty.

As such, I'd suggest unmarking it as Invalid, but I'll leave the decision to the bugsquad

[Gunnar Hjalmarsson (gunnarhj)]

In the linked branch lp:~gunnarhj/gdm/language-menu I propose code that
would fix this bug in the GDM package in Ubuntu 11.04. Given that code,
ca-ES@valencia is displayed as "Catalan (Spain) - valencia".

If you want to check it out, packages with the changes are available at
https://launchpad.net/~gunnarhj/+archive/language-menus

[Pau Iranzo (paugnu)]

Hi,

The name we're using when translating into ca-ES@valencia is «Catalan (Valencian)». Actually, this is the name we're using on Lauchpad:
https://translations.launchpad.net/+languages/ca@valencia

Could it be possible to use that one (Catalan (Valencian)) instead of «Catalan (Spain) - valencia»?

[AsstZD (eskaer-spamsink)]

No. "ca" CAN be translated to "Catalan" etc. "ES" CAN be translated to "Spain". "ca-ES@valencia", "ca@valencia", or "@valencia" CAN NOT be translated, as "valencia" is just a arbitrary string made up by user, the same as in "en_US@kjsdawe" or "sv_SE@wmedv" or any other one someone can dream of. It's not in standard, it's just what it is, and show it like this is the best way.

[AsstZD (eskaer-spamsink)]

Right way to do it is to register the new language code for Valencian dialect of Catalan. and use it instead of this hack.

[Pau Iranzo (paugnu)]

«Valencian» has already a code assigned by the IANA on the BCP47 standard:
http://www.iana.org/assignments/language-subtag-registry

The subtag is:
Type: variant
Subtag: valencia
Description: Valencian
Added: 2007-03-06
Prefix: ca
Comments: Variety spoken in the "Comunidad Valenciana" region of Spain,
  where it is co-official with Spanish.

As you can see, the description says «Valencian». There is no «official» name for this variant, for that reason, «Valencian» translators started to use the name «Catalan (Valencian)» because it is the best descriptive option, the code is usually ca-valencia/ca-ES-valencia/ca@valencia/ca-ES@valencia (po files use the @ for subtags). We use this name on:

GNOME (http://l10n.gnome.org/languages/ca@valencia/)
KDE (http://i18n.kde.org/stats/gui/trunk-kde4/team/ca@valencia/)
OpenOffice and LibreOffice (http://translations.documentfoundation.org/ca_XV/)
VirtualBox (http://www.virtualbox.org/ticket/2018)
Mozilla (https://addons.mozilla.org/ca/firefox/language-tools/)

As you can see, KDE and GNOME, two of the most important free software projects are using this name. I don't see any reason to change it. And it is very important for Valencian users to have a descriptive name of their variant.

What I'm saying is:

code: ca@valencia (or ca-ES@valencia)
name: Catalan (Valencian)

Is that possible?

[Gunnar Hjalmarsson (gunnarhj)]

The proposed code for @variants is general, and intended to be applied to all translation variants. What Pau suggests would require special code just for @valencia. Technically it would of course be possible (and not very difficult), but I fear that such a hack wouldn't be approved for policy reasons.

Pau: It's a little ironic that you use GNOME to support your suggestion. Please check out the discussion at https://bugzilla.gnome.org/show_bug.cgi?id=602965 to see what I mean. ;-) My code is part of the work with bug 693337, and it will probably become an Ubuntu only solution.

It may be worth mentioning that GDM and language-selector use different methods for converting code to menu labels. In language-selector the language code 'ca' is shown as 'Catalan; Valencian' and in GDM as just 'Catalan'.

Another note: The code for @valencia will be either 'ca@valencia' or 'ca_ES@valencia'. On my box it's the latter, and the reason for that is that I'm using FileZilla, whose @valencia translation - unlike all other @valencia translations - resides under a ca_ES@valencia directory. Without FileZilla, the code on my box would be 'ca@valencia', which would have been shown in GDM as just 'Catalan - valencia'. One reason for this proposed behavior is the gettext bug 700213...

Sorry for bothering you with these details, but they show that it's more into it than you may first think. Bottom line is that we'll probably have to be content for now with the somewhat simplistic solution I'm proposing. After all it's better than not showing @variants at all.

[AsstZD (eskaer-spamsink)]

GNU Locale format != BCP 47
@modifier field has no relation to either script or variant subtags of latter format. Also the latter allows to have script, variant, and any user pecularities in several subtags of one language tag, former does not.

[Arne Goetje (arnegoetje)]

On 01/11/2011 07:41 AM, Gunnar Hjalmarsson wrote:
> The proposed code for @variants is general, and intended to be applied
> to all translation variants. What Pau suggests would require special
> code just for @valencia. Technically it would of course be possible (and
> not very difficult), but I fear that such a hack wouldn't be approved
> for policy reasons.

Actually, I think we can improve this without having special code only
for @valencia, since all @variations would be affected. (see below)

> Pau: It's a little ironic that you use GNOME to support your suggestion.
> Please check out the discussion at
> https://bugzilla.gnome.org/show_bug.cgi?id=602965 to see what I mean.
> ;-) My code is part of the work with bug 693337, and it will probably
> become an Ubuntu only solution.
>
> It may be worth mentioning that GDM and language-selector use different
> methods for converting code to menu labels. In language-selector the
> language code 'ca' is shown as 'Catalan; Valencian' and in GDM as just
> 'Catalan'.

Yep. The language/country names and their translations in
language-selector are taken from the iso-codes packages, i.e. they are
the names defined in ISO639-1,2,3 and ISO3166 respectively. In GDM on
the other hand the language/country names are hard coded, means the
translations in both applications would be done separately and may
conflict with each other, since they are two different upstreams.

Since the @variations are not standardized in the iso-codes package, and
I couldn't think of a "proper" solution which would work for all
@variations, I did it like this in language-selector: the identifier
behind @ in the locale name is chopped off and glued to the (translated)
language name in the format "language[ (country)][ - variant]", where
country and variant are optional. This also means, the variant name
currently cannot be translated.

Now, the proper solution would probably be something like this:
 * a "text" file with a mapping between language codes, whose names and
translations need to override the ones from iso-codes
 * this file needs to be parsed and be translatable
 * it should be possible to use the same source for multiple programs
(gdm, language-selector, ...)

One solution I could think of is this:
We create a new package, "iso-codes-overrides" or something like that.
It contains a xml file in the same format as the iso639 or iso639-3 file
in the iso-codes package, where we have the following fields:
 id="ca@valencia"
 name="Catalan (Valencia)" (or something similar)
 comment="Catalan dialect spoken in Valencia" (a text comment for
translators to let them know what this entry is about)

Then we just need to steal^Wcopy the packaging scripts from the
iso-codes package to make the file translatable. This will then show up
as a translatable package in Launchpad.
Of course this solution would be probably Ubuntu (and maybe debian)
only. The next step would be to replace the hard coded language/country
names in gdm with gettext calls to our new package and the iso-codes
package, in this order. In language-selector we would just need to
insert and additional gettext call.

These overrides would IMHO affect the following lan...

[Pau Iranzo (paugnu)]

OK, I can understand now the problem with this (thanks for the explanations). It's a shame we have two variants in the same country.

The proposed solution by Arne looks good to me. I know this would be only for Ubuntu and Debian, but it would be worth it: in all Valencian schools we have installed a variation of Ubuntu (Lliurex) which is using at this moment a restricted locale (qcv) and a lot of modifications to implement Valencian language. If we can work something out (for example what Arne proposes), it would be perfect. I mean: Ubuntu/Debian is far too long the most used distribution in Valencia, if this change were done, we would solve one of our main problems when selecting the system language.

[Gunnar Hjalmarsson (gunnarhj)]

Like Pau I like your idea, Arne, and I agree that it would be much less 'hackish' than doing it for just one @variant. As regards GDM it would require a method that passes the efficiency restrictions of the boot sequence. Guess you know better than me how hard that may be. ;-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 2.32.0-0ubuntu7

---------------
gdm (2.32.0-0ubuntu7) natty; urgency=low

  [ Gunnar Hjalmarsson ]
  * debian/patches/40_one_lang_option_per_translation.patch:
    - The option list in the language chooser changed so the items
      represent available translations instead of locales
      (LP: #693337).
    - setlocale() validation removed (not applicable).
    - Show locale variants in the list of language options
      (LP: #408474).
  * debian/patches/36_language_environment_settings.patch:
    - Skip the encoding part in the dmrc "Language" value. It's not
      a locale name, so let's not give the impression it is.
    - Take main country code into account when generating
      a locale name for LC_MESSAGES.

  [ Kees Cook ]
  * Restore 24_respect_system_minuid.patch: upstream does not handle
    reading login.defs yet (LP: #708911).
 -- Gunnar Hjalmarsson <email address hidden> Thu, 10 Feb 2011 10:07:31 +0100