In the course of testing https://bugzilla.redhat.com/show_bug.cgi?id=889562 , it became apparent that, while both GNOME and anaconda are deriving their list of available keyboard layouts from xkb in some way, they're not really doing it the same - and GNOME appears to be doing it better.
The ordering is somewhat different, the displayed name is slightly different, but most obviously, GNOME offers quite a lot of layouts anaconda does not.
I went through every language offered on the very first page of the installer, checking the 'Set keyboard to default layout for selected language.' checkbox each time and proceeding to the main hub to see what keyboard would be selected. Here are the three languages I found appeared to have a 'matching' layout listed in GNOME, but no matching layout available to anaconda.
For all of these, if you search in the GNOME keyboard layout tool, you will find what appear to be matching layouts. These layouts do not appear in anaconda's list. The Indian ones both have (m17n) in the name and result in some kind of ibus configuration, so that could be why anaconda is not picking them up. But Croatian seems to be just the XkbLayout 'hr', so I have no idea why anaconda is missing that.
These are just the tip of the iceberg, though, there are lots of other layouts GNOME has that anaconda is missing. It's easy enough to side-by-side the lists, with anaconda running in a VM and GNOME on the host system, and compare. Could be to do with restricted package set available to the installer environment somehow, I suppose.
The Assamese and Marathi translations are complete or close to it, so it's a shame we're not setting their keyboard layouts correctly. Nominating as NTH.
We are just using libxklavier's foreach_language_variant . I have no idea why those layouts are missing.
I'm guessing the ibus-based ones may be missing as we don't actually have ibus in the anaconda environment, but that's a pure guess. I have no idea about Croatian.
Discussed at 2012-01-03 go/no-go meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-03/f18_final_gono-go_meeting.2013-01-03-17.01.log.txt . Accepted as NTH: this should be a safe fix and improves keyboard mapping during install which is obviously desirable and not fixable with an update.
Thanks to Rui Matos I now know where the problem lies here. The thing is that for the Croatian layout (and probably also the others) its XML definition doesn't include the language specification and is therefore not listed by the foreach_language_variant. It can be gotten by the foreach_layout and foreach_layout_variant, but this way we still don't get the information that Croatian layout is for the Croatian language (unless doing some "substring magic").
So while I can add the code that would add the Croatian layout to the list of available layouts I cannot make it selecting that layout for the Croatian language by default. (without some "substring magic")
It sounds like it would be better just to fix the Croatian layout in xkb, maybe? Can we get a list of layouts which are missing this information, and then re-assign the bug to xkb and possibly send it upstream? Would that be do-able?
(In reply to comment #5)
> It sounds like it would be better just to fix the Croatian layout in xkb,
> maybe? Can we get a list of layouts which are missing this information, and
> then re-assign the bug to xkb and possibly send it upstream? Would that be
Yeah, I believe it should be fixed in xkb because that way also the other projects could make use of corrected data. Rui is now dived in xkb files and their processing so he could be the right person to help here. Adding him to CC list and setting needinfo.
Ping? Rui, did you get anywhere with trying to fix Xkb for the Croatian problem?
No, sorry. The best way to fix this "defaults" issue once and for all is going to be https://github.com/mike-fabian/langtable which Mike Fabian started recently.
Anaconda is using langtable now (thanks!) - perhaps we could move this
to modified for f20.
Sounds reasonable. I'll try and find a minute to check that the list looks comprehensive.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.
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 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 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 18'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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.