Bug 432887 - Make anaconda set locale from the map
Summary: Make anaconda set locale from the map
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 12
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 545502 (view as bug list)
Depends On:
Blocks: AnacondaUI
TreeView+ depends on / blocked
 
Reported: 2008-02-14 22:20 UTC by Linus Walleij
Modified: 2018-04-11 18:38 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-28 18:20:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Linus Walleij 2008-02-14 22:20:00 UTC
As discussed on fedora-devel.

Whether this is a bug or a feature can be discussed, but when
you choose English (US) language for your installation, 
anaconda sets /etc/sysconfig/i18n to contain something like:

LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"

While you may still choose a totally different locality for
your time (the click map) later, LANG remains en_US (the
latter part of this is actually wrong then).

So when you run "locale":

[rodd@localhost ~]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

I believe very many of these LC_* settings should actually
be set to a locale matchin (as closely as possible) the
choice on the map. So if you click Paris, most things except
the language switching things need to be set to fr_FR.UTF-8

Will it disturb some program?

Obviously, and due to how locales are used as filename for 
finding a hash for translations, setting the locale to 
en_FR.UTF-8 will not work, sadly. :-/

Comment 1 Christian Rose 2008-02-15 00:11:13 UTC
To make it more clear: This is about modifying Anaconda to distinguish LANGUAGE
from LOCATION, instead of making some messed up assumption about the latter from
the former.

By differentiating LANGUAGE (affecting LANG and LC_MESSAGE settings) from
LOCATION (affecting most other LC_* settings) in Anaconda, we'd come a long way
in sorting out the most common problems with the current situation for the
majority of use cases.

The separation between LANGUAGE and LOCATION suggested above is also essentially
what Windows does by default and has done for several years (I beleive this was
introduced starting with Windows 2000).
If you install an American English copy of Windows, the Windows installer will
let you alter the "Regional Settings" during install time, affecting numbers,
currency, time and date display, measurement system etc. right from the
Installer. By picking the "Swedish" option from the list in the Installer, you
will end up with an American English Windows, but with all those regional
settings set to their Swedish counterparts.



Comment 2 Hans de Goede 2008-02-15 07:59:33 UTC
Maybe better then setting different LC_xxxx settings to different values,
potentially confusing (badly written) program, it would help if all of the
en_FOO settings in /usr/share/i18n/locales where exposed (better?) during
install time.

Maybe it would be an idea to check the selected LANG setting during the timezone
selection and if the language is en_US (iow the user just clicked next) and the
timezone is not US, pop up a dialog advising the user the use a more appropriate
en_FOO one?

For example, I always do next -> next in the keyb and language selection screens
(and so does everyone I know who wants English), and then when I get to the
timezone selection I click on Amsterdam. It would be great if anaconda could
then throw up a dialog saying something like:

You've selected Amsterdam, but have selected English (US) as language settings.
This will result in things like metrics (meters versus inches), data format and
papersize (A4 versus letter) all defaulting to US style settings. A more
appropriate English setting for Amsterdam would be English (International, Euro
currency) do you want to change the language settings to this?

Yes / No



Comment 3 Matěj Cepl 2008-02-17 14:52:00 UTC
(In reply to comment #2)
> Maybe better then setting different LC_xxxx settings to different values,
> potentially confusing (badly written) program, it would help if all of the
> en_FOO settings in /usr/share/i18n/locales where exposed (better?) during
> install time.

No, badly written programs needs to be fixed — that’s The Right Way™.

Comment 4 Linus Walleij 2008-02-17 20:01:26 UTC
FWIW here is the GNU C Library manual page detailing the
use of some of the different local variables:
http://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html#Locale-Categories

Sadly it's incomplete but they are quite self-explanatory luckily.

Comment 5 Jeremy Katz 2008-02-20 23:55:22 UTC
(In reply to comment #0)
> I believe very many of these LC_* settings should actually
> be set to a locale matchin (as closely as possible) the
> choice on the map. So if you click Paris, most things except
> the language switching things need to be set to fr_FR.UTF-8

Except that a lot of non-French cities use the Paris timezone.  And similar for
timezones across the globe.  Not to mention that the timezone database doesn't
have a mapping from City -> Locale and that would have to be maintained
somewhere by someone (hint: maintaining it in anaconda is a guaranteed path of
failure ;-)

(In reply to comment #2)
> Maybe better then setting different LC_xxxx settings to different values,
> potentially confusing (badly written) program, it would help if all of the
> en_FOO settings in /usr/share/i18n/locales where exposed (better?) during
> install time.

Exposing all of these knobs will just lead to *more* confused users.

I pretty strongly feel that the installer isn't the place to put this,
especially given how much of it is user-centric preferences.  If someone wants
to write the control panel applet that looks like the Windows one and has it
write out the appropriate ~/.i18n with LC_* set appropriately and get it added
to the distro, then that's fine, but I really don't think it's something every
user should have to be exposed to.

Comment 6 Matěj Cepl 2008-02-21 00:13:50 UTC
Jeremy, please, consider this once more -- and keep separately the first two
comments. IMHO, the second one (to be able to set all locale variables in
anaconda) is probably not the great idea, because these are really per-user
variables.

However, we have to guess somehow value of LANGUAGE and IMHO the first is
disputing whether we are doing a good job on this, which I think we don't.
Saying, that somebody wants LC_PAPER=en_US just because he wants his messages in
English (or LC_MONETARY=se_SE, which means Euro, just because he lives in Chile)
is probably suboptimal.

Guess we must somehow, and it will never be 100% correct, but it seems to me,
that guessing by the timezone will get better results than guessing by language
of messages.

The City->Locale database is a problem, but don't we have it already somewhere
in glibc?

Comment 7 Nils Philippsen 2008-02-25 11:22:34 UTC
Matej, using the timezone list of cities wouldn't be a good idea IMO:

- Sometimes the "nearest city in your timezone" isn't in your country at all
(and far from the nearest city on the map), so it doesn't give a good hint about
locale settings.
- Glibc/tzdata upstream won't maintain any more cities beyond those needed to
identify timezones.

Ideally, we would ask the user "where do you live?"/"where is this machine
located?" on installation and would map that to timezones and locale settings, but:
- We need to ask these questions in "natural" terms (i.e. like countries,
regions, counties or equiv., cities). Not everybody knows the ICBM coordinates
of where they live ;-).
- Then we'd have the problem field of countries/regions with ... let's say
disputed autonomy (e.g. Taiwan, Northern Cyprus or the most recent example,
Kosovo) -- How would we offer people to choose these without offending those
parties that deny that these regions/countries are autonomous?

NB: I think this is not only an anaconda and/or s-c-date issue -- should we deal
with this in the "distribution" component?

Comment 8 Matěj Cepl 2008-02-25 17:27:28 UTC
(In reply to comment #7)
> NB: I think this is not only an anaconda and/or s-c-date issue -- should we deal
> with this in the "distribution" component?

Probably. And yes, you are right, I haven't thought this through. And yes, it is
certainly not anything time sensitive. Just I think that the current state
(Australians with Letter paper) is not acceptable.

Comment 9 Nils Philippsen 2008-02-26 09:58:55 UTC
(In reply to comment #8)
> Just I think that the current state (Australians with Letter paper) is not
> acceptable.

The same with me. It should probably go like this:

- Ask for the language in English (which sets the language, nothing more) if it
isn't known.
- Ask for the location (there's the question how to do and maintain this, we
don't want to keep a database for every village on the planet, neither do we
want to require Google maps ;-).
- Extrapolate TZ, date and time, paper, currency defaults from that.
- Offer a way to change these defaults.



Comment 10 Matěj Cepl 2008-02-26 14:21:51 UTC
(or, just not to be English- and paper-centric, Argentinians and Quebecians --
how are these names spelled properly? -- with Euro because of es_ES and fr_FR
locale; although the latter may like it ;-)).

Comment 11 Nils Philippsen 2008-02-26 14:37:38 UTC
The es_AR and fr_CA locales cover these or how do I misunderstand you ;-)?

Comment 12 Matěj Cepl 2008-02-26 14:46:27 UTC
Yes, they would but they will never be selected when we ask just for language
(in the same manner as en_AU won’t be selected as poor Aussies have default
Letter paper which comes from en_US).

Comment 13 Rodd Clarkson 2008-02-27 00:25:05 UTC
I should stress (as the poor Aussie ;-]) that I select English US (not English
AUS) but then again I never realized that my choice of language would affect so
many other 'unrelated' things like paper, metrics, etc.  English is spoken all
over the world and I choose US English because, as a programmer, I don't need to
see works like 'center' underlined in applications because the US can't spell
;-p, and I'm not really that anal about how words are spelt as long as people
understand what I mean (the last joke aside).

There must be a better way to set these locale values than having a spurious
guess based on my choice of language in an installer.

Comment 14 Rodd Clarkson 2008-02-27 00:27:21 UTC
I should add that this might be better handled in first-boot (and has anyone
ever thought of a first-login for when new users login for the first time that
might allow them to customize this sort of thing?)

Comment 15 Jef Spaleta 2008-05-04 22:53:18 UTC
Extrapolating the firstboot concept..to a per user firstlogin concept
is...intriguing.  Since we can't actually 'fix' Rodd's mental
brokenness..voluntarily supporting the United States cultural empiralism by
choosing to us US English as the preferred language on his desktop....a
firstlogin would allow for self-medication by such broken users.

And in fact we can pretty much count on similar situations on multiuser
setups...like say university computer labs. How many people have foreign
co-workers who want to easily work in their native language but need to interact
with the native preferences like physical paper size?  I use to, but then I
instituted a draconian US-only policy backed back a threat of deportation.  But
I doubt most people are in a situation where they can be as openly nationalistic
as I am.

-jef




Comment 16 Rodd Clarkson 2008-05-05 01:15:35 UTC
Thanks Jef (I think?)

There is another way around this.  The only reason I use US English is that
there is enough syntax highlighting (always a good thing) without having
underlines under words too because I spelt something 'center' and not 'centre'
(and other such things).

Maybe it might be simpler to change the programming languages so that they spell
centre right and this I won't have to put up with this problem.

Seriously, however, language really isn't a good indicator of locale.  There's
been plenty of examples of people who for what ever reason find that the
language they use and the locale they live in just don't match and I still can't
see what using the time-zone stuff wouldn't work.

Or maybe what's needed is for the installer to check the time-zone against the
language choice and then prompt if there are discrepancies.

Comment 17 Hans de Goede 2008-05-05 07:23:46 UTC
Hi All,

I would like to thank Rodd for being vocal about this issue, as it really is an
issue, but I think he is indeed a bad example as the use case for this.

So let me offer myself as example I and many other Dutch users prefer our
computer programs to be in English not Dutch, because some things just don't
translate well. Example: Bold (as in font) becomes vet, which translates back to
fat, etc. Really Dutch computer programs are just an abonimation. So I choose
leave the language selection in the installer to the default, and then Anaconda
I live in Amsterdam, after which I get Letter paper, inches and all those other
stuff Americans use because they cannot follow international metrics and iso
standard paper sizes.

Another example Max Spevack will soon be living in Amsterdam, guess what his
language will be set too, and guess what his location selection on the map will
be, yes Amsterdam so that his computers clock matches local time. I'm pretty
sure he won't be taking tons and tons of letter paper boxes with him, so sooner
or later he will be using A4 paper to print.


Comment 18 Rodd Clarkson 2008-05-05 23:52:39 UTC
I'm  not sure there is much difference between my useage case and yours (both of
our native languages cause us issues with using a computer) but thanks for the
support.

In fact, I'm beginning to wonder whether I filed the bug the wrong way.

Maybe I should have said that the US is broken and that we need to create a
cludge/hack to work around them. ;-]


Comment 19 Jens Petersen 2008-05-06 07:40:24 UTC
(In reply to comment #0)
> Whether this is a bug or a feature can be discussed, but when
> you choose English (US) language for your installation, 
> anaconda sets /etc/sysconfig/i18n to contain something like:

> I believe very many of these LC_* settings should actually
> be set to a locale matchin (as closely as possible) the
> choice on the map. So if you click Paris, most things except
> the language switching things need to be set to fr_FR.UTF-8


Comment 20 Jens Petersen 2008-05-06 07:57:56 UTC
Oops, just a few observations about the status quo:

> (In reply to comment #0)
> > Whether this is a bug or a feature can be discussed, but when
> > you choose English (US) language for your installation, 
> > anaconda sets /etc/sysconfig/i18n to contain something like:

At least for Australia, being able to choose "English (Australia)" would make
sense, no?

For the text installer, there is no choice of dialects for the install language
- just "English", etc.  Does the GUI installer provide more choices?

Users can choose their preferred locale at login from gdm of course.
But that is not good enough?

Comment 21 Bug Zapper 2008-05-14 05:12:26 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Tony Fu 2008-09-10 03:11:14 UTC
requested by Jens Petersen (#27995)

Comment 23 Bug Zapper 2008-11-26 02:06:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 24 Jens Petersen 2009-08-31 08:13:19 UTC
Maybe geoip would help with this?

Comment 25 Bug Zapper 2009-11-16 08:01:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 26 Martin Gracik 2009-11-24 12:36:01 UTC
I don't think taking the locales from the timezone or even geoip is a good idea.

For example my use case is that, I live in Czech Republic, that's why I set up the timezone to Prague/Czech Republic, but I want the numbers, money and all these things to be set to Slovak, because I'm from Slovakia, and I'm used to it, but I don't want any of the software I use to "talk" to me in Slovak, or Czech, because the translations are horrible, so I want everything to be in English.

As I remember, the way Windows does it, you have 3 different settings.
You have to select a Location, that affects the numbers, and all these things, then you select a Language, that affects, the applications, and then you have a timezone. They are not connected, you can select whatever you want during the install, if you want to.

Comment 27 Martin Gracik 2009-12-09 08:55:41 UTC
*** Bug 545502 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.