GNOME Bugzilla – Bug 684565
Typing based search for finding a keyboard layout is suboptimal
Last modified: 2013-05-09 19:35:13 UTC
One of the big use cases for using the Layout tab of the Region and Language is if you can't type with the system selected default keyboard layout, and need to find the one that matches how you type. In this case presenting the user with a big list of layouts in the 'Select an input source to add:' dialog, and expecting them to type to filter the search and find a specific layout is problematic. Much better would be to have a categorized or tree based filtering in this case. Even if it is different from other parts of how search is the gnome-control-center is done, it makes sense given the use case.
you have a point...
*** This bug has been marked as a duplicate of bug 684540 ***
Seems related to that bug but doesn't seem to be a duplicate. The bug noted above is about typing a non-English name for input sources. This bug is about not typing at all.
(In reply to comment #3) > Seems related to that bug but doesn't seem to be a duplicate. The bug noted > above is about typing a non-English name for input sources. This bug is about > not typing at all. Right, for that we'll need to re-work how we present the input sources. I think a 2 level deep tree would work well with the 1st level being either the language or the country/territory. I'd love some design input here. On the technical side, to do such a thing, we'll need to 1) add more metadata to the various layouts in xkeyboard-config since they are very incomplete right now in advertising which language/territory/country they apply to; 2) have a library that can be used by the various desktop modules to handle the mapping of ISO language and territory codes to their translated names. This is basically what gdm-languages.c in the g-c-c tree does and I have some proto patches locally that I'll try to move to gnome-desktop for the next cycle if people agree it's a good idea.
(In reply to comment #4) > Right, for that we'll need to re-work how we present the input sources. I think > a 2 level deep tree would work well with the 1st level being either the > language or the country/territory. I'd love some design input here. Countries/territories often brings their lot of political tensions (e.g would you write « Taiwan, Republic of China » or « Taiwan, Province of the People's Republic of China » ? Don't answer ;) ) That's the same reason why distributions like Fedora have strict policies against showing flags. Languages is much more neutral, and it seems more related to the action at hand: allowing the input of a language. > 2) have a library that can be used by the various desktop modules to handle the > mapping of ISO language and territory codes to their translated names. This is > basically what gdm-languages.c in the g-c-c tree does and I have some proto > patches locally that I'll try to move to gnome-desktop for the next cycle if > people agree it's a good idea. Could the DB Anish talks about in bug 689269 help here?
A new design for the add language dialog is here: https://live.gnome.org/Design/SystemSettings/RegionAndLanguage#Input_Sources_Updates
Created attachment 231239 [details] [review] common: Show popular languages in their own language Instead of the current one. In the add dialog, show two columns, one in their own language, and one in the current language. Make the filtering match both columns.
Created attachment 231240 [details] [review] common: Add 2nd column to the region choosers Show a 2nd column with the region name/language name in its original language. Make the filtering match both columns.
Comment on attachment 231240 [details] [review] common: Add 2nd column to the region choosers Some languages aren't getting translated correctly though, so marking as needs-work.
Created attachment 231241 [details] What it looks like
Looks nice. I like it.
This was re-designed for 3.8.