Description of problem: Currently, during the installation of the Fedora 17 (and all previous versions), anaconda will ask user to select their language and a keyboard layout preference. Then a few screens later it would ask a user for TimeZone settings... but the time zone setting is not used to determine user's locale -- ie. chosing English as language and TimeZone as Europe/London will install os with default US locale How reproducible: always Steps to Reproduce: 1. Install new Fedora 2. Choose English and your keyboard of choice 3. Choose Europe/London as a timezone Actual results: Locale set to en_US.UTF-8 Expected results: Locale set to en_GB.UTF-8 Additional info: Simple solution would be to present a user with a map, so user can select their location/time zone, language and keyboard setting on the first screen. that would allow anaconda to correctly determine the locale settings: ie. chosing Europe/London with English would set the locale to en_GB ie. chosing Canada/Toronto with Englsih would set the locale to en_CA Benefit to Fedora: less anoyed users outside of US, who need to adjust almost everything including their printer's paper (apparently A4 is a standard around the world, while US/CA still use Letter).
During Fedora 18 installation you can choose English (United Kingdom) as a language which results in en_GB.UTF-8 locale used during the installation and also on the installed system. But this works only for languages/locales we have some translations for. But this is a wider issue affecting more languages.
I was just about to file another bug for this until I noticed this one. It still is a problem in F18. After installing a recent F18 GNOME Live CD on my system I noticed my locale was set to en_US for everything as reported by "locale" in the terminal. This was after choosing American English (AFAIK, don't remember exactly) as the language and the keyboard layout in Anaconda. But I selected Amsterdam as my time zone because I live in the Netherlands. In response to comment #1, my issue with your solution is that I like the language of my OS to be American English, but want to use a Dutch locale. As I live in Europe I need to use the comma as the decimal separator, not the dot used in the USA or the UK. So your solution doesn't work for me as it assumes the locale to be identical to the chosen language. So to fix this, just like the reporter I think it would be best to choose the locale based on the time zone instead of the language. Or maybe simply ask directly what locale the user would like, if that would not complicate the installation process too much?
(In reply to comment #2) > (..) > So to fix this, just like the reporter I think it would be best to choose > the locale based on the time zone instead of the language. Or maybe simply > ask directly what locale the user would like, if that would not complicate > the installation process too much? I think user should be asked directly. I give you an example. Currently, when I install my OS, I select following options: Language: English Keyboard layout: Polish Time zone: Europe/London and I end up with American English selected and a ',' instead of the '.' on my numeric keyboard... not ideal. What I really want is British locale with an easy access to Polish characters. Assuming locale based on time zone would not work for travellers -- I travel frequently and change my time zone according to the city I am in, so it would confuse me further, if all would change based on where I am. At the moment, I can change my locale to British English after system is installed, but it does not change dot's behaviour on the numeric keyboard -- it still enters coma instead of the dot -- agree, this should not be keyboard layout related, but locale dependent.
The only problem here are less experienced users that have no idea what the locale is. From our (Anaconda) point of view it would be much easier to have a screen where user could select the locale than playing this "guessing game". Language, locales, keyboard layouts and timezone are separate settings and deriving one from the other is always hard and not working for all cases. But, on the other hand, confusing users with a screen they don't understand is not better. There should probably be a wider discussion about this topic. It should be quite easy to make particular changes in Anaconda then.
(In reply to comment #4) > The only problem here are less experienced users that have no idea what the > locale is. From our (Anaconda) point of view it would be much easier to have > a screen where user could select the locale than playing this "guessing > game". Language, locales, keyboard layouts and timezone are separate > settings and deriving one from the other is always hard and not working for > all cases. But, on the other hand, confusing users with a screen they don't > understand is not better. There should probably be a wider discussion about > this topic. It should be quite easy to make particular changes in Anaconda > then. Agree, there should be right questions asked, in a right order. At the moment user is asked to select language and keyboard, then location. So user chooses English, which sets the US locale; then user selects location, which only applies to the time zone. This has more confusing consequences for un-experienced users when it comes to printing -- suddenly printer stops working as US uses Letter paper size, while rest of the word uses ISO A4. So the right question would be: Select your location? then based on location locale, language and keyboard could be automatically preselected for user. Advanced options could be collapsed, so only users who needs them would ever look there. The keyboard layout and numeric's dot key behaviour is a separate issue, yet related to the locale I think.
(In reply to comment #5) > (In reply to comment #4) > > The only problem here are less experienced users that have no idea what the > > locale is. From our (Anaconda) point of view it would be much easier to have > > a screen where user could select the locale than playing this "guessing > > game". Language, locales, keyboard layouts and timezone are separate > > settings and deriving one from the other is always hard and not working for > > all cases. But, on the other hand, confusing users with a screen they don't > > understand is not better. There should probably be a wider discussion about > > this topic. It should be quite easy to make particular changes in Anaconda > > then. > > Agree, there should be right questions asked, in a right order. At the > moment user is asked to select language and keyboard, then location. So user > chooses English, which sets the US locale; then user selects location, which > only applies to the time zone. This has more confusing consequences for > un-experienced users when it comes to printing -- suddenly printer stops > working as US uses Letter paper size, while rest of the word uses ISO A4. > > So the right question would be: Select your location? What options would you give users here? Countries? Timezones? Or something else? And from where would you get those? > > then based on location locale, language and keyboard could be automatically > preselected for user. Advanced options could be collapsed, so only users who > needs them would ever look there. How would you do that automatically? I'm afraid there is no algorithm to do that. And "Advanced options" is something everybody clicks just to find out what it hides. And then these people get confused and we are at the same point. I believe the only working solution here is a mapping from language to locale, keyboard layout and timezone. But this is something that should be a separate package maintained by i18n team(s). The other fact is that the installer is supposed to install the system. Everybody can change their locale settings in the installed system. This isn't something that needs to be done during installation. Whether it is easy to do that afterwards or not is a different issue. Maybe there should be a panel in gnome-control-center allowing users to set locale. But the fact that such screen is missing in Gnome (or whichever DE) is not a reason for adding it to the installer.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > The only problem here are less experienced users that have no idea what the > > > locale is. From our (Anaconda) point of view it would be much easier to have > > > a screen where user could select the locale than playing this "guessing > > > game". Language, locales, keyboard layouts and timezone are separate > > > settings and deriving one from the other is always hard and not working for > > > all cases. But, on the other hand, confusing users with a screen they don't > > > understand is not better. There should probably be a wider discussion about > > > this topic. It should be quite easy to make particular changes in Anaconda > > > then. > > > > Agree, there should be right questions asked, in a right order. At the > > moment user is asked to select language and keyboard, then location. So user > > chooses English, which sets the US locale; then user selects location, which > > only applies to the time zone. This has more confusing consequences for > > un-experienced users when it comes to printing -- suddenly printer stops > > working as US uses Letter paper size, while rest of the word uses ISO A4. > > > > So the right question would be: Select your location? > What options would you give users here? Countries? Timezones? Or something > else? And from where would you get those? I see it this way: present users with the map and ask them to select their location / country -- users living in countries with multiple time zones would be familiar with the time zones choice, so they would click on "their" region (ie. in Canada, USA or few others). Based on this simple selection installer could set the locale easily - including time zone, keyboard layout and language. It is not ideal, as some countries are multilingual, so displaying an additional drop down with languages choices could be an option. But to simplify for most of the users I believe visual map would be more than enough. At the moment (just installed Fedora 18 Beta), I get a question to select my language -- by default it has "English (United States)" selected and while it's fine, it's not clear to users, they may be able to select other English (ie. British or Canadian), it's also a drop down difficult to scan through to see all possible options. Other problem -- there is a large group of people, who like to use English as OS language while they want to keep their local locale. Ie. my sister lives in Spain, but she prefers to keep her OS in English. My native language is Polish, but I prefer to have my OS in English. > > > > then based on location locale, language and keyboard could be automatically > > preselected for user. Advanced options could be collapsed, so only users who > > needs them would ever look there. > How would you do that automatically? I'm afraid there is no algorithm to do > that. And "Advanced options" is something everybody clicks just to find out > what it hides. And then these people get confused and we are at the same > point. Advanced options could be triggered with a command line switch. Either way, I really don't like this Apple-like approach of simplifying everything -- good defaults are important, but ability to tweak by power users is important too. If I wanted to be treated as an idiot, I would have bought apple mac in a first place. Remember: locale, language and keyboard are key settings of the system. Some users won't be able to type their password correctly with wrong keyboard layout. Others won't be able to print, if system will assume US locale... > I believe the only working solution here is a mapping from language to > locale, keyboard layout and timezone. But this is something that should be a > separate package maintained by i18n team(s). It will fail for my sister, who wants to use her OS in English, but have her locale set to Spain. > The other fact is that the installer is supposed to install the system. > Everybody can change their locale settings in the installed system. This > isn't something that needs to be done during installation. Whether it is > easy to do that afterwards or not is a different issue. Maybe there should > be a panel in gnome-control-center allowing users to set locale. But the > fact that such screen is missing in Gnome (or whichever DE) is not a reason > for adding it to the installer. Installer will install default set up for the system, so it is important to give users a chance to set the defaults right. Agree, it can be done after the installation, but I would prefer to have this sorted during the installation. Same with packages choices -- I really liked the idea I could select packages I wanted to install individually, with the new installer, I can only choose groups, which is not ideal and makes me to spent time *after* installation on adding missing packages. As you said, installer is supposed to install the system, so it should allow quick install for newbies and advanced install for power users.
(In reply to comment #4) > The only problem here are less experienced users that have no idea what the > locale is. Then the installer needs to explain what locale means, or describe it without using jargon like 'locale'. gnome-control-center calls this 'Formats'. Perhaps 'Regional Formatting' would be clearer. > From our (Anaconda) point of view it would be much easier to have > a screen where user could select the locale than playing this "guessing > game". Language, locales, keyboard layouts and timezone are separate > settings and deriving one from the other is always hard and not working for > all cases. Indeed. Although even with such a screen, it would still be good to make an educated guess for the default. > But, on the other hand, confusing users with a screen they don't > understand is not better. It doesn't have to be confusing. The Region & Language section of Gnome's control center appears to be pretty understandable. Despite being strongly correlated to language, time zone, keyboard layout and what-have-you, the locale setting is ultimately a personal preference. It is orthogonal (correlation notwithstanding) to those other region/language settings, and as such must be selected separately. It's not strictly derivable as a function of those other settings. The question then, is whether to present the user with this selection at install time, or to make an informed guess and let the user alter it at their leisure post-install. Selecting a locale is not a "power user" feature. It is a feature that affects normal users, and can cause confusion and miscommunication (consider ambiguity between recognising American vs non-American date format for example). However, perhaps the default is good enough for the majority, so it's a philosophical question of utilitarianism vs "regional equal treatment". (Vaguely comparable to whether accessibility configuration is to be presented during installation, I suppose, though the impact is less severe.)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Fedora End Of Life from comment #9) > This message is a reminder that Fedora 17 is nearing its end of life. Still relevant in Fedora 18.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.