desktop-packages team mailing list archive

[Gunnar Hjalmarsson <868149@xxxxxxxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/868149

Title:
  Need to set $LANG from .dmrc for backwards compatibility

Status in “lightdm” package in Ubuntu:
  Fix Released
Status in “lightdm” source package in Oneiric:
  Fix Released

Bug description:
  This is fallout from bug 864618: In that bug 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.

  However, set_language() also sets the $LANG variable from ~/.dmrc,
  which we need for backwards compatibility and derivatives.

  So what should happen is that all the code which does the `locale -a`
  guesswork needs to be dropped, and only these parts remain which
  evaluate ~/.dmrc.

  Please see http://pad.ubuntu.com/locale-handling for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/868149/+subscriptions