GNOME Bugzilla – Bug 729208
g-i-s should offer full lists of keyboard layouts / input methods as a third level of expansion as it used to
Last modified: 2014-09-10 11:11:46 UTC
g-i-s gives me a pretty weird selection of keyboard layouts when I pick Canada as my location. I'm filing that separately as it's a bug in an underlying component, but there does appear to be a g-i-s specific bug here too. The first five or so layouts it offers don't include "English (Canada)" or "English (US)". After clicking ... I have "English (US)" but not "English (Canada)" (or many, many other layouts - I know there are 400+ actually available, and the list is only showing 30 or so). The search box at the bottom seems to only search the still-filtered list of layouts offered, and there is no further level of 'expansion' apparent, so it seems there is just no way for me to access anything beyond this filtered list of layouts. IIRC with the old g-i-s there were *two* levels of expansion - first you got the list of 5 or so layouts, then a ... gave you the 'longer filtered' list of 30 or whatever, then a further ... let you pick from the complete set. That second level of expansion appears to have been lost.
Filed https://bugzilla.gnome.org/show_bug.cgi?id=729211 for the problem of the system default layout (the one the user probably just chose as part of OS installation) not being in the filtered lists offered in g-i-s.
Ping? This is a major problem, and not resolved in 3.13.
This is mostly a design issue. For the specific bug with English (Canada) see bug 729210
Let's generalize this design issue out, as it actually affects two places in g-i-s. When g-i-s was redesigned recently (3.10? 3.12?) a significant change was made to selection of both Region and keyboard layout / input method. Previously, you first got a very heavily filtered list of possibilities (the region selection was filtered based on the language you picked, the layout / input method filtered on the language+region combination, IIRC) - just five or six - at first. It had a '...' on the bottom you could click to access a less-filtered list of 30 or so results. It then had a *third* level of expansion (another ...) which let you access all possible choices. After the redesign, only the first two levels remain. You cannot access the full list of possibilities for either region or keyboard layout during g-i-s. I can perhaps see the intent here - we should be able to get it right at least to ~30 possibilities, why confuse people? But I don't think it actually works. Someone reported one obvious problematic case on G+ yesterday (I can't find the link as G+ search sucks, apologies): people often want to install in English no matter where they live, because English is kind of an international lingua franca, particularly among 'technical' people. You really can't reasonably assume that anyone picking English as their language will be in one of five or six regions, or even one of ~30 regions. They could quite literally be in *any region at all*. It's slightly less common for other languages, but it certainly happens. People move across the world, but still want to use their native language on their computer. People want to install in a foreign language to help them learn it. The same applies to keyboard selection. People move across the world and take their keyboard with them - I used a UK English keyboard for the first four years I lived in Canada. People want to use a US English layout even though they live somewhere completely different, again because it's kind of a 'standard' (and some tasks, like coding, tend to work best with a US English layout and very poorly with some 'national' layouts). I just don't think it's safe to believe the heuristics can ever be good enough for all cases. The 'all choices' get out clause really needs to be available. It's worth noting that of course users aren't stupid, and they've usually arrived at g-i-s after going through an installer with a less strict approach to filtering. They almost certainly know that the system *can* use the region or keyboard layout they want, and this stupid tool is actively taking trouble not to give them the option. That makes people more frustrated than the case where they don't know the capability exists at all. "I know I need X, why won't you give it to me?!" is much more frustrating than not knowing X exists at all.
actually that complaint was #732736, i thought it was a G+ post for some reason...not sure if it's best to have separate bugs for keyboard layout and region, or have this unified one.
I'm running into this as well. In my case it's for example not possible to select the combination English, United States and Swedish. A potential issue that I see is that this may make it hard or even impossible to enter correct information on subsequent pages, like the user's name or password, since selecting a keyboard layout immediately changes the active layout.
Created attachment 285420 [details] [review] keyboard: Include all layouts This patch adds all remaining keyboard layouts to the list on the keyboard page. I'm not sure exactly what the design is behind the keyboard page. If the idea is that the list should have three levels then some additional work is needed.
Created attachment 285422 [details] [review] region: Show the more button when there are extra regions The "more" button is added too early to the region page. Essentially the list is empty when it is added, so there are no extra regions to show. But I also noticed that the button is not updated properly when the user goes back and selects another language. This happens for example when selecting English, going back and select Swedish and then go back again and select English. Calling gtk_list_box_invalidate_filter when the page is mapped makes the button show up correctly.
I've been looking at this bug for a while and it's giving me a headache. The title has little correspondence with the initial report, and proposes a solution rather than stating a problem. I'm honestly struggling to parse comment #4. Please provide a concise description of the actual issue, as experienced. (In reply to comment #6) > I'm running into this as well. In my case it's for example not possible to > select the combination English, United States and Swedish. ... This doesn't provide enough information. Please say exactly what you trying to achieve.
(In reply to comment #9) > (In reply to comment #6) > > I'm running into this as well. In my case it's for example not possible to > > select the combination English, United States and Swedish. ... > > This doesn't provide enough information. Please say exactly what you trying to > achieve. OK. Summary: Gnome-initial-setup does not include all keyboard layouts on the keyboard layout selection page, so the user can be prevented from selecting the correct one. Steps to reproduce: 1. Launch gnome-initial-setup 2. Select "English" on the first page (language). Click Next. 3. Select "United States" on the second page (region). Click Next. 4. Select "Swedish" on the third page (keyboard). Expected result: The keyboard layout "Swedish" should appear in the list. Actual result: The keyboard layout "Swedish" does not appear in the list. Notes: Gnome-initial-setup only presents keyboard layouts based on the selected language and region. Specifically, this happens in cc-input-chooser.c in get_locale_infos (). The keyboard layouts retrieved from gnome_xkb_info_get_layouts_for_language () are added first, followed by the keyboard layouts from gnome_xkb_info_get_layouts_for_country (). While it is a good thing to make an educated guess about which keyboard layout the user most likely wants, this still leaves out quite a lot of possible options.
(In reply to comment #10) Thanks. I guess this is primarily because we only show keyboard layouts for the selected language and region. We probably coupled these settings in order to reduce the number of choices that are presented - otherwise you end up in the situation of having two locale selections - one for the display language and formats, and one for the keyboard layout. I can see why you might want to use, say, a Swedish keyboard with a US English display language, though.
The latest Region and Language settings designs are pretty much what we want here, I think: https://wiki.gnome.org/Design/SystemSettings/RegionAndLanguage#Add_Input_Source_Dialog It would make sense to have initial setup work in the same way, with a separate two-step process for selecting the input language and layout.
allan: just as comment #4 said: "You really can't reasonably assume that anyone picking English as their language will be in one of five or six regions, or even one of ~30 regions. They could quite literally be in *any region at all*. It's slightly less common for other languages, but it certainly happens. People move across the world, but still want to use their native language on their computer. People want to install in a foreign language to help them learn it. ... I just don't think it's safe to believe the heuristics can ever be good enough for all cases. The 'all choices' get out clause really needs to be available." it's a nice theory that 'region' and 'input method' can be unproblematically derived from 'language' and thus you can save people trouble with aggressive filtering, but it just isn't *true*. there's no entirely reliable mapping. If I'm understanding the design you reference correctly, yes, it would work. So long as the user can choose any possible setting for 'language', 'region' and 'input method' without their choices for any one or two of those things unavoidably restricting the available choices for the other, the bug would be resolved. It's fine if it's hidden behind an expander or whatever, the choice just needs to be there.
(In reply to comment #13) I asked for succinct summary. You've quoted your original comment back, with additional commentary. I'm sorry, but I'm not going to spend my time deciphering this kind of noise. > If I'm understanding the design you reference correctly, yes, it would work. Good.
Ok, I think there's a huge misunderstanding here and people are talking past each others. I myself was confused by the current state of g-i-s in this area since I thought the code was still doing mostly what g-c-c does, just with a different face, but it turns out that I was wrong since Matthias changed the code last December. Basically what's currently in g-i-s tries to implement the designs Allan linked above. But I believe that the implementation doesn't match the design in what it actually does. Let's go back to what g-c-c does (and what I thought g-i-s was doing): a) Language selects a full locale (e.g. en_US) and sets it as LANG (i.e. what effectively ends up as LC_MESSAGES aka the UI locale) b) Region selects a full locale (e.g. fr_FR) and sets it as as LC_TIME, LC_NUMERIC, LC_MONETARY, etc, i.e. it sets the "formats" locale aka "how your clock looks" and "how your numbers are formatted in the UI. The current g-i-s doesn't do b) entirely and instead splits the UI for choosing a) into 2 steps which confusingly are called Language and Region selection but what they do is actually choose the first and second elements of a locale which gets applied as LANG. e.g. first you choose "en" and then you choose "UK" and en_UK ends up applied as LANG. Now, I don't know if Matthias misinterpreted the design or the design missed the point of a) and b) as explained above. If the current g-i-s implementation is indeed what the design intended, then we can't show all "regions" in the 2nd step since that wouldn't make any sense since it's not how locales work, i.e. you can't mix the 1st and 2nd elements of a locale arbitrarily. In fact, a locale *is* a language, i.e. en_UK and en_US are two *different* languages technically and we just can't change this fact. I think the problem is that some people (including me FWIW) think of choosing a "Region" as choosing the "formats" locale, so I'd say we should either re-label the current "Region" page in g-i-s to something else or just remove it and go back to only have the Language page with a single list like ... English (United Kindgom) English (United States) ... Otherwise, if the design wanted the Region page to actually be about the "formats" locale then the whole page needs to be fixed.
Review of attachment 285420 [details] [review]: BTW, the previous comment was about the first two pages only. This patch is fine and I'll push it to make all keyboard layouts available independently of the LANG locale chose in the first two pages.
Comment on attachment 285420 [details] [review] keyboard: Include all layouts Attachment 285420 [details] pushed as 198e3bb - keyboard: Include all layouts
Yeah, at least it seems like we really do have two cases here, one simple one (keyboard) and one more complex ("region"). I'll fix the topic of this bug, and we can close it as soon as the keyboard bit is fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=732736 looks like the good place to handle the question of what 'Language' and 'Region' selection are supposed to do (and whether we need a better concept).
(In reply to comment #15) > If the current g-i-s implementation is indeed what the design intended, then we > can't show all "regions" in the 2nd step since that wouldn't make any sense > since it's not how locales work, i.e. you can't mix the 1st and 2nd elements of > a locale arbitrarily. In fact, a locale *is* a language, i.e. en_UK and en_US > are two *different* languages technically and we just can't change this fact. That is true and also what makes the whole region selection page confusing, especially if you don't know how locales are defined. But there's also a bug in the current implementation where it won't show all valid "regions" for the selected "language." Pick for example "English" on the language page. That should give you approximately 20 regions to choose from. But the list of regions will only show six of them. This is by design and the rest of them should be visible by pressing a "more" button in the last row of the list. But due to the way the list is constructed the button doesn't appear. Maybe this is not that important to fix it's going to be redesigned anyway, but that's otherwise what my second patch is attempting fix.
Marcus: ah, apologies, I missed that wrinkle; I think it might be best to track that as yet a third bug if it's not a part of the (presumed) redesign?
I've pushed that patch, so at least the code works as I meant it to, originally. Now we can replace it with something else :-)
I think we are done with this for 3.14: - the language page shows all locales (in the second level) - the region page is skipped - the keyboard page shows all keyboard layouts (in the second level)