Description of problem: Installed Fedora 18 yesterday using the XFCE spin Live ISO. After installation, the locale is set to English (USA), despite me specifying Australia/Melbourne as the timezone. I also had this issue with my previous Fedora 17 installs. Finding out how to change it is a bit hard. A google search for "fedora 18 set locale" produces results, however none of the first few matches say that the 'system-config-language' application is the one to use to change it system wide, and it isn't installed by default anyway. I've thought about this a bit, and speculated that it might have been left on the U.S. locale as our keyboard layout is U.S., which I selected, while our spelling etc. is mostly British. If this is the case, perhaps the timezone information could be used to set the locale instead, or perhaps used to select the locale if a U.S. keyboard layout is selected. Having the locale left as U.S. is particularly frustrating as spelling dictionaries end up incorrect, and imperial rather than metric measurements are used in applications. Version-Release number of selected component (if applicable): Fedora 18 install. How reproducible: Every install. Steps to Reproduce: 1. Select US keyboard layout. 2. Select Australia/Melbourne as the timezone 3. Complete the install. Actual results: Locale left as "English (USA)", rather than "English (Australia)". Expected results: Locale set to "English (Australia)", as implied by Australia/* timezone. Additional info:
Can you please try this again with F19 beta when it is released (in a month or two) and let us know if it is still broken? We've just committed some stuff that should help this case out. Thanks.
Ok, I'll give it a go and let you know.
Hi, Just tried out Fedora 19 (XFCE) Beta, I still didn't end up with an Australian locale after installation. Firstly, I tried an English (United Kingdom) installation, as English UK is the spelling we use. 1. Selected English (United Kingdom) as installation language 2. Did not select keyboard layout checkbox to match installation language, as Australia uses US layout 3. Selected Australia/Melbourne as timezone 4. Did install. 5. Locale set to en_GB, not en_AU Secondly, I tried the English (US) installation, as I suspect it would be common for Australian installs to accept the default. 1. Used default English (United States) as installation language 2. Selected Set keybaord to default layout for selected language, as Australia uses US keyboard layout. 3. Selected Australia/Melbourne as timezone 4. Performed installation. 5. Local set to en_US, not en_AU
The only way to get en_AU is to select it! :) Your step (1) decides the locale not the timezone. It would be nice if we could decouple language and region from locales but that is not how glibc locales work alas. Second related problem is getting en_AU to fallback to en_GB translations rather than en_US.
Jens, there doesn't seem to be anywhere to select an Australian locale during installation.
Okay that is a bug then :) I think the problem is that there is no en_AU translation for anaconda and that then leads you into this twisty path of locales and timezones. Anaconda team: can something be done to add en_AU to the list of anaconda languages?
(In reply to Jens Petersen from comment #6) > Okay that is a bug then :) > > I think the problem is that there is no en_AU translation for anaconda > and that then leads you into this twisty path of locales and timezones. > > Anaconda team: can something be done to add en_AU to > the list of anaconda languages? As long as there is no English (Australian) [en_AU] translation, the language won't appear in the first screen. I'm closing this as CANTFIX. If anybody things this should be resolved and will suggest a practically usable solution, feel free to reopen this bug.
" If anybody things this should be resolved" I know of at least one person who thinks it should be resolved - his name is in the Reported field above. "a practically usable solution" Use the selected timezone as an indication of locale. Most of the time it will be correct. If the selected timezone doesn't match the install translation, present a list of locales to select from after the timezone has been selected.
Further to this, given that there are a total of 12 non-US and non-UK English locales, this is likely to be a problem for more than just Australians.
FWIW, it's fairly easy to change this after install in GNOME; just go to the Region & Language control center applet (you can launch it directly by opening the overview and searching for 'regio'), and you can set Language and Formats there. English (Australia) shows after you expand the list one time (it only shows very common locales at first, click the three dots in a vertical line to expand the list). If you have only one user with admin privileges, this setting should then be applied systemwide. If you have more than one user, or your user doesn't have admin privileges, you can set the systemwide locale via the "Login Screen" button. Out of interest, is there something specific you stand to gain by having the locale set correctly, or is it just a desire to have it correct? I'm in Canada, but I usually just keep the en(US) locale, it's close enough in all practical respects.
For Fedora 20 I'm planning to come up with locale selection for the Anaconda, but I'm not going to do such major changes in this phase of F19. Using timezone is not a generally working solution (think about timezones like US/Central etc.).
(In reply to Adam Williamson from comment #10) > Out of interest, is there something specific you stand to gain by having the > locale set correctly, or is it just a desire to have it correct? I'm in > Canada, but I usually just keep the en(US) locale, it's close enough in all > practical respects. Default papersize A4 might be a reason.
well, if I was in AU I'd probably plump for the UK locale as the 'closest bet', rather than US, but the principle is roughly the same.
Discussed at 2013-06-12 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final-blocker-review-5.2013-06-12-16.01.log.txt . Agreed this is rejected as a freeze exception: given the way F19 does locale selection - it's directly tied to translation availability - there isn't a small, simple fix here, we can't just 'add' AU somehow. Any change that fixes this would necessarily be a larger scale revamp of how locale selection actually works, per comment #11. So it's not appropriate for a freeze exception, it's more F20 stuff.
(In reply to Mike FABIAN from comment #12) > (In reply to Adam Williamson from comment #10) > > Out of interest, is there something specific you stand to gain by having the > > locale set correctly, or is it just a desire to have it correct? I'm in > > Canada, but I usually just keep the en(US) locale, it's close enough in all > > practical respects. > > Default papersize A4 might be a reason. That is one. (The "PC (Print Cartridge) Load Letter" error message was common here on HP printers, because you had A4 paper in the printer, but the PC sending a print job to it was set to Letter due to a US locale. It actually doesn't make sense that it occurs in the Office Space movie, unless that was set in Canada or similar rather than the US. In short, I've known WTF "PC Load Letter" means for a long time.) Metric instead of imperial units of measurement. I was taught in primary school that we use space as thousands separators rather than a comma. Having the incorrect spell check dictionaries is one of the most obvious differences when using a US locale. 'colour' vs 'color', 'neighbour' vs 'neighbor', and all the 's' vs 'z's e.g. 'initialise' vs 'initialize'.
well, like I mentioned, the AU locale is clearly a top-down fork of the UK locale ;), so that would be the obvious one to choose when AU isn't available. But probably not worth bikeshedding this further.
(In reply to Adam Williamson from comment #14) > Discussed at 2013-06-12 freeze exception review meeting: > http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final- > blocker-review-5.2013-06-12-16.01.log.txt . Agreed this is rejected as a > freeze exception: given the way F19 does locale selection - it's directly > tied to translation availability - there isn't a small, simple fix here, we > can't just 'add' AU somehow. Any change that fixes this would necessarily be > a larger scale revamp of how locale selection actually works, per comment > #11. So it's not appropriate for a freeze exception, it's more F20 stuff. I'm happy enough with it being dealt with properly in a future release of Fedora. However, would it be possible to have the system-config-language package installed by default in F19 to at least make changing the locale significantly easier? If people go looking for a utility to change the locale, and system-config-language is installed, I think they'll guess that this is how they change it.
Well, that would be the obvious approach if it actually worked. https://lists.fedoraproject.org/pipermail/devel/2013-June/183925.html Still, even if we fix it, the correct way to configure this in GNOME is with the GNOME control center; that's how GNOME is designed. The GNOME devs would still want to explicitly exclude s-c-language from their spin, as they do all config tools which essentially compete with the GNOME control center.
Hmm. I'm using XFCE, and I don't think there is a way to set locale within XFCE. I wasn't aware that it can be changed in Gnome, and as the Anaconda installer seemed to be taking care of those sorts of settings (e.g., keyboard, timezone), thought that that must be where people are setting it, and if it isn't correct, people were just accepting not quite right spell check dictionaries, or errors like PC Load Letter. If system-config-language is now broken, what is the alternative? When I originally went looking to fix this issue I went looking for a file in /etc/ that specified the locale, but couldn't find one. From memory I think I initially resolved it using a grub kernel command line option, however that is a pretty big hammer to solve this sort of problem, and I thought it should be easier than that. Once I found system-config-language, I used that instead and it has worked for me.
'localectl' should be what you need. I hope s-c-language can be fixed, though.
Note:- system-config-language is not completely broken. I see requests since last two months where people are just interested to set the locale using system-config-language and i have tested this and its working fine. I used MATE and system-config-language also and I see language is set correctly though UI shows group does not exists message. When you ask system-config-language to set some language it does this two things. First to check for packages if available to install and also set the locale. So, overall for such users who just want to set locale and no extra packages to be installed for them, system-config-language is working in any desktop environment.
system-config-language sets locale in /etc/locale.conf
ah, that's good. I thought that the 'it's completely broken' stuff meant it wasn't writing via localed.
One can use 'localectl' (see 'man localectl') to change the locale.
(In reply to markzzzsmith from comment #9) > Further to this, given that there are a total of 12 non-US and non-UK > English locales, this is likely to be a problem for more than just > Australians. If you want to hack up your own Anaconda with Australian English without upstream support you can probably do that easily. Then simply install the update inside the live environment prior to install (or if it's for a bunch of people, add it to a local repo or something). Tested this on Fedora 19: yumdownloader --source anaconda rpm -ivh anaconda*src.rpm cd ~/rpmbuild/SPECS patch -p0 < /tmp/anaconda-en_AU.patch #(attached) rpmbuild -ba anaconda.spec #(preferably use mock) -c
Created attachment 766413 [details] Patch to anaconda.spec to hack in Australian English support
I should add that I think it would be good to have support for more language dialects/variations by default. I realise in the present method this means we need translations, hence the hack above. In terms of Anaconda it could be a sublist under a parent language like "English" that you click which goes to another list to refine choice (Android has a similar setup in places). Also the string in Anaconda that says something like "Please select a language to use for installation" should probably be more explicit to say this will also be the default language for the resulting system, or something. -c
vpodzime already mentioned upthread that he's thinking of revising this entirely to better capture the separation between language and locale.
(In reply to Adam Williamson from comment #28) > vpodzime already mentioned upthread that he's thinking of revising this > entirely to better capture the separation between language and locale. Done, patches pushed. A video preview of the new behaviour can be seen at: http://vpodzime.fedorapeople.org/locales_changes.webm
(In reply to Vratislav Podzimek from comment #29) > Done, patches pushed. A video preview of the new behaviour can be seen at: > http://vpodzime.fedorapeople.org/locales_changes.webm That looks fantastic, thanks for your work. -c
Vratislav’s new code is in f20. I.e. we can probably close this bug?
(In reply to Mike FABIAN from comment #31) > Vratislav’s new code is in f20. I.e. we can probably close this bug? Works for me, implementation is nice.