Most Chinese uses 'us' layout and the majority expects 'Chinese' enables an input method so the 'cn' layout could confuse people. Wish to move 'cn' layout from evdev.xml to evdev.extras.xml not to be shown by default.
Created attachment 137063 [details] [review] Patch for rules/base.xml.in This is the proposal patch.
Why do such layouts that do nothing but include another layout even exist? On one side people are bothered by exotic layouts cluttering, on the other side people are being confused by multiple names for the same thing, and translators get additional lines too. I recommend to hide likewise ara(qwerty), ara(qwerty_digits), sy(basic). More, these layouts should be deleted, perhaps after being hidden for some time. I see a slight use in sy(ku), sy(ku_f), sy(ku_alt) which include the corresponding layouts in tr (because then Syrian Kurds can find layouts for them by country), although I’d still rather not have them, but Chinese are smart enough not to search a Latin layout by viewing the China layouts and Syrian Arabs are presumably more confused about the peculiarity of an “Arabic (Syria)” layout than hindered from finding the Arabic layout by its not being listed for their country.
Created attachment 137104 [details] [review] Patch of rules/base.xml.in for Arabic (In reply to Socialdarwinist from comment #2) > Why do such layouts that do nothing but include another layout even exist? I may not understand your question. Several GUI applications likes gnome-control-center refers evdev.xml only but not evdev.extra.xml . We'd hide "cn" layout in desktop applications by default. > I recommend to hide likewise > ara(qwerty), ara(qwerty_digits), sy(basic). More, these layouts should be > deleted, perhaps after being hidden for some time. > > I see a slight use in sy(ku), sy(ku_f), sy(ku_alt) which include the > corresponding layouts in tr (because then Syrian Kurds can find layouts for > them by country), although I’d still rather not have them, but Chinese are OK, the second patch moves ara(qwerty), ara(qwerty_digits), sy(ku), sy(ku_f), sy(ku_alt) to extra.xml. Do you mean sy(basic) is sy layout with no variant? > smart enough not to search a Latin layout by viewing the China layouts and > Syrian Arabs are presumably more confused about the peculiarity of an > “Arabic (Syria)” layout than hindered from finding the Arabic layout by its > not being listed for their country. Probably I don't understand this issue.
sy(basic) only includes ara(basic) without adding anything. I have raised the question why such layouts at all exist. For the same reason that we move layouts to base.extras.xml we could delete these kinds of layout altogether: They clutter layout lists and do add even less than exotic layouts.
The idea is that for some country their basic layout is just a copy of some other layout/variant. Technically it is not nice (may be even stupid) indeed. But I would like to eliminate the situation when users from some countries would be frustrated with 'nothing for us here' thought. Does this make sense?
Yep, I had realized that (I said “because then Syrian Kurds can find layouts for them by country”), however one could play down the importance. Like in this case, I find it hard to imagine that Chinese in China could not find the US layout because they search it by their state People’s Republic of China. And with the current border issues in Iraq and Syria the analogon for Kurds living in Kurdistan is even more questionable. For Arabs in Syria, do they ever think that there is a specific Syria-layout like Germans could think there is a Germany-specific layout? Sadly the empirical data about keyboard layout consciousness lacks, people only come to the keyboard layout guys when things break; else people only look incredulously that somebody cares about keyboard layouts even if one does try to get some empirical input. Maybe there aren’t any frustrations at all because there aren’t any expectations because people have no thoughts about keyboard layouts. It is even a first-world luxury to be able to think that the computer has to produce the characters as they are written on the physical keyboard – in the non-Latin world the measurements are different. But there is a way whereby the expectation considerations can become irrelevant: Country information has to be moved to the XML data. I don’t know yet how and if the keyboard layouts in far future should be saved in different ways than in files named by country codes, but for compatibility one can move all the country data to the XML. Isn’t this exactly what the XML tag countryList is for in the XML data? If I understand it correctly, somebody just needs to mow down the old wrappers and add the appropriate XML data. After that it becomes the business of other software like gnome-keyboard-applet, fcitx and so on if there are double displayings, whereas such wrappers – fake layouts – just force duplicate display. It won’t make sense however to add the country <iso3166Id>CN</iso3166Id> to the default US layout; the rule is of course that there must be a specific connection to a country. Thus I can conclude that the cn(basic) wrapper has to be deleted. The only objection is that someone might actually use it, but if a cleanup is done to remove such wrappers it can be announced once, and in the cn(basic) case the fallback if a layout is removed is us(basic) anyway. If grandfathering is too gracious, a software product becomes a big ball of mud. And maybe it is better to remove the fake layouts because we do not want to lie to the users. We have been delicate about the sensitivities of the users, then we have to cease lying to them and take hard but honest steps.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/75.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.