Hide Forgot
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. :-/
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.
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
(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™.
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.
(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.
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?
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?
(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.
(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.
(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 ;-)).
The es_AR and fr_CA locales cover these or how do I misunderstand you ;-)?
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).
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.
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?)
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
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.
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.
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. ;-]
(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
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?
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
requested by Jens Petersen (#27995)
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
Maybe geoip would help with this?
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
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.
*** Bug 545502 has been marked as a duplicate of this bug. ***