Bug 42857 - Suggested property for locale aimed at region specific formats settings
Summary: Suggested property for locale aimed at region specific formats settings
Alias: None
Product: accountsservice
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Matthias Clasen
QA Contact:
Depends on:
Reported: 2011-11-12 12:09 UTC by Gunnar Hjalmarsson
Modified: 2018-08-07 09:31 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:

Adds property for regional formats (14.62 KB, patch)
2011-11-12 12:09 UTC, Gunnar Hjalmarsson
Details | Splinter Review

Description Gunnar Hjalmarsson 2011-11-12 12:09:24 UTC
Created attachment 53463 [details] [review]
Adds property for regional formats

Currently (0.6.15) the only available language/locale property is the Language property. To facilitate a more fine tuned setting of the user language/locale environment, more properties would be useful.

The attached patch suggests the addition of the FormatsLocale property and the SetFormatsLocale method, aimed at a locale name for region specific formats such as date/time, numbers, currency, default paper size, etc. It's a stand-alone addition of code, using the code for Language and SetLanguage as model.

Based on how Ubuntu deals with language/locale related user data, I have some other ideas of how accountsservice might be improved, but they will need to be discussed. I'll get back to you on the topic.
Comment 1 Martin Pitt 2011-11-24 06:07:57 UTC
To put a little more meat behind this proposal: our intention is to write the language as $LANGUAGE and the region as $LANG into ~/.pam_environment, so that it applies to all sessions independent of the login manager/GNOME.
Comment 2 Matthias Clasen 2011-11-28 12:12:54 UTC
If you are going to put it into $HOME anyway, then why get accountsservice involved in the first place ?
Comment 3 Martin Pitt 2011-11-28 22:36:58 UTC
So that any GUI which sets the language (which might be more than just control-center) will use that, and avoid duplicating code. Also, because this is not at all Ubuntu/distro or even Linux specific, so at some point it should/could get upstream as well.
Comment 4 Gunnar Hjalmarsson 2012-01-03 22:58:43 UTC
I'll try to expand on and possibly clarify Martin's comments above about what we are doing in Ubuntu with respect to language/locale settings.

The user settings in Ubuntu for language and regional formats have been stored in ~/.profile for a long time. In 12.04 we will use ~/.pam_environment instead, which is a natural choice for environment settings and typically not the subject of manual editing (unlike ~/.profile).

So, language and regional formats
- are set as environment variables,
- are ultimately stored in the same file, and
- are mutually dependent on each other (due to LANG).

As regards language we make use of the LANGUAGE priority list, for which reason we have added some preprocessing code etc. to accountsservice (illustrated graphically at https://wiki.ubuntu.com/LanguageSettings). Even if it's simpler to handle regional formats, it makes sense and is smoother to use the same interface as for language. Hence this request for an additional accountsservice property/method pair.

You can say that we are extending accountsservice's service with respect to language and regional formats. AccountsService, which is usable cross-desktop and with a readiness to comply with requests for changes/additions, appears to be a suitable owner of code for handling some language/locale related bits and pieces.

I see a few advantages with the choosen approach. Some of them are more or less Ubuntu specific, such as:

* Our previous efforts to make language-selector and gdm 2's
  language chooser play well together resulted in unnecessary
  duplicate of code. Through a couple of accountsservice patches
  we have been able to get rid of that code duplication.

* Facilitate switch from the language-selector UI to the region
  module in gnome-control-center.

* Having code for both language and regional formats in the same
  place facilitates a slightly complex migration to 12.04, e.g.
  migrating of data from ~/.profile to ~/.pam_environment.

But there are also some generally applicable advantages: 

* The use of ~/.pam_environment makes it easy to use alternative
  login managers.

* ~/.pam_environment is read by PAM early (before e.g. ~/.profile
  is sourced), so users are free to fine-tune the locale settings
  to their liking by editing ~/.profile.

* A language chooser on the login greeter works well also on
  systems with a more advanced type of language settings, i.e.
  which includes the LANGUAGE environment variable. The chooser
  in lightdm-gtk-greeter is an example of that.

We believe that this approach to dealing with language settings may be beneficial also to other distros but Ubuntu. Therefore we think that - besides the patch attached to this bug - it would be a good idea to implement upstream some of the functionality in the currently Ubuntu specific accountsservice patches. This is what I meant with "other ideas" in the bug description.

It would be great if we could talk more about this topic. I don't know where such a discussion should be hold. This bug report is probably not the best place.
Comment 5 Stef Walter 2013-04-16 11:54:02 UTC
We talked about this property at the XDG Summit yesterday and came up with a Locale property, that I'd like to implement.

Locale is an a{ss} of the various locale environment variables: http://www.gnu.org/software/gettext/manual/html_node/Setting-the-POSIX-Locale.html#Setting-the-POSIX-Locale

We tried other alternatives but all of them were inherently limiting for the general purpose. 

When the Locale property is set, then Language is automatically filled in from the LANGUAGE, LC_MESSAGES etc. environment variables as expected.

The two use cases here are:
 * Have the login screen print messages for the user in the right language,
   with right dates, formats and so on.
 * Set up the environment variables properly early in boot.
Comment 6 Stef Walter 2013-04-16 11:55:49 UTC
I hope to rework the patch shortly.
Comment 7 GitLab Migration User 2018-08-07 09:31:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/22.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.