Need to set $LANG from .dmrc for backwards compatibility

2011-10-05 09:53, Martin Pitt skrev:
> ... we disabled the set_language() call as it invalidly sets $LANG to
> the "Language" property of accountsservice, which cannot work because
> $LANG is a locale and "Language" is only a language name.

We currently derive locales from language denotations, such as 'es_ES' or 'de', all the time. The main problem is that LANG represents regional formats in Oneiric, not language.

Gunnar Hjalmarsson [2011-10-05 14:47 -0000]:
> We currently derive locales from language denotations, such as 'es_ES'
> or 'de', all the time.

But we should really avoid doing that, as it can never be correct for
$LANG. It's fine for LC_MESSAGES and LC_CTYPE.

> The main problem is that LANG represents regional formats in
> Oneiric, not language.

$LANG has always been defined to specify a locale, not a language.
This is neither Oneiric nor Ubuntu specific, but standard
gettext/POSIX behaviour.

  http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html

2011-10-05 17:24, Martin Pitt skrev:
> Gunnar Hjalmarsson [2011-10-05 14:47 -0000]:
>> We currently derive locales from language denotations, such as 'es_ES'
>> or 'de', all the time.
>
> But we should really avoid doing that, as it can never be correct for
> $LANG. It's fine for LC_MESSAGES and LC_CTYPE.

We don't do it for $LANG. $LANG is set from a separate UI (currently in language-selector) that lists the available UTF-8 locales. So I think we are agreed.

>> The main problem is that LANG represents regional formats in
>> Oneiric, not language.
>
> $LANG has always been defined to specify a locale, not a language.
> This is neither Oneiric nor Ubuntu specific, but standard
> gettext/POSIX behaviour.
>
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html

I meant that LANG in Oneiric *contains a locale name* that represents regional formats as opposed to a locale name that represents a language/translation. So we are most likely agreed on this too. :)

lightdm 1.0.2 now pulls the "Language" value from ~/.dmrc and sets the LANG environment variable to that. If accountsservice is in use then LANG is not set.

Robert,
Does it make sure that the value is a valid locale name? I ask since GDM in Natty (and in case of backports also in Lucid and Maverick) uses the ~/.dmrc "Language" field for storing language denotations such as 'es_ES' or 'de', i.e. not for storing locale names.

Gunnar, no, it just sets LANG to that value without any checking. So we're back to square one... I initially was treating it as a language value, but then pitti said it's a locale, and now you're saying it is a language. I'm lost.

Didn't we introduce the "Langlist" field for that, in order to not break other DMs which expect a locale there?

So old GDM had it set to a locale:
http://projects.gnome.org/gdm/docs/2.20/configuration.html

Did it change in the new GDM, or is this an Ubuntu specific thing?

This bug was fixed in the package lightdm - 1.0.1-0ubuntu4

---------------
lightdm (1.0.1-0ubuntu4) oneiric; urgency=low

  * debian/patches/04_language_not_to_LANG.patch:
  * debian/patches/04_dmrc_set_LANG_only.patch:
    - Replace LANG disabling code with proper fix (LP: #868149)
  * debian/patches/03_launch_dbus.patch:
  * debian/patches/05_gdmflexiserver_not_in_PATH.patch:
    - Refreshed
  * debian/patches/06_accounts_service_timeout.patch:
    - Fix D-Bus timeout when accounts service not installed (LP: #866035)
  * debian/patches/07_long_password_crash.patch:
    - Fix crash with long passwords (LP: #817186)
 -- Robert Ancell <email address hidden> Thu, 06 Oct 2011 15:45:21 +1100

On 2011-10-06 07:46, Martin Pitt wrote:
> Didn't we introduce the "Langlist" field for that, in order to not break
> other DMs which expect a locale there?

No, I'm afraid we didn't. "Langlist" contains e.g. 'de:en_GB:en' while "Language", which in GDM 2 was related to GDM_LANG, contains only 'de' (i.e. the first "Langlist" element, which should be one of the items that /usr/share/language-tools/language-options outputs).

On 2011-10-06 07:48, Robert Ancell wrote:
> So old GDM had it set to a locale:
> http://projects.gnome.org/gdm/docs/2.20/configuration.html
>
> Did it change in the new GDM, or is this an Ubuntu specific thing?

It's an Ubuntu specific thing in GDM 2. (In GDM 3 ~/.dmrc isn't used.)

So, in order to find out the size of this possible problem for LightDM, we should better ask ourselves if there is any Ubuntu derivative that
- used GDM up to Natty AND
- uses LightDM in Oneiric AND
- does not use accountsservice in Oneiric.
If not, there may be no need to do anything.

Otherwise, the language2locale() function I proposed in https://code.launchpad.net/~gunnarhj/lightdm/lang-chooser/+merge/78226 might be handy. You could use that function to convert ~/.dmrc "Language" values that does not contain a '.' before setting LANG.

Gunnar Hjalmarsson [2011-10-06 19:10 -0000]:
> > Did it change in the new GDM, or is this an Ubuntu specific thing?
>
> It's an Ubuntu specific thing in GDM 2. (In GDM 3 ~/.dmrc isn't used.)

Argh, why did we use that? Whenever we discussed that we were quite
adamant to not redefine the meaning of existing fields, to not break
other DMs and backwards compat. :-( As it seems that existing
configuration files can now contain a locale (as it should), or a
language (which really is broken), I guess we can only apply a
heuristic, as e. g. en_GB is both (but more likely a language, as we
never officially supported non-UTF8 locales and gdm never allowed you
to set one).

> Otherwise, the language2locale() function I proposed in
> https://code.launchpad.net/~gunnarhj/lightdm/lang-chooser/+merge/78226
> might be handy. You could use that function to convert ~/.dmrc
> "Language" values that does not contain a '.' before setting LANG.

Please note. By definition, a language name does not have enough
information to turn it into a proper locale for $LANG, unless you also
know which country the user is. I rather propose to apply a heuristic
to find out whether it's a language or a locale, and assign it to
$LANGUAGE/$LANG respectively.

I think this heuristic should work, assuming that we only support
UTF-8 in .dmrc:

  '.' in the name → locale; break
  no '_' in the name → language; break
  now we have something like ll_CC[suffix]
  ll in {'en', 'es', 'zh', 'pt'} → language
  else it's a locale

That works for any ll_CC.UTF-8 (locale), simple language ("de"),
specially handled country specific language (en_GB, zh_TW), UTF-8
locales without suffix (sr_RS@latin, sr_RS).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I think the best answer to the question why we used the ~/.dmrc "Language" field for storing language is that we converted the locale chooser of GDM 2 to a language chooser. We did talk about the risk for confusion, but adamant? Not as far as I recall.

It struck me that the language2locale() function I mentioned relies on an Ubuntu specific accountsservice patch, so it can't be used in the way I suggested in my previous comment anyway.