From Fedora Project Wiki
(Add EurKEY) |
No edit summary |
||
| Line 5: | Line 5: | ||
# Some layout is also available in certain countries but not recognized, e.g. Dvorak in China and India. | # Some layout is also available in certain countries but not recognized, e.g. Dvorak in China and India. | ||
# Produce redundancy, like QWERTY in US, CN, IN are actually the same, but need to list 3 times. | # Produce redundancy, like QWERTY in US, CN, IN are actually the same, but need to list 3 times. | ||
# Some layouts, like EurKEY, do not belong to one particular country | |||
===Proposed Keyboard Layout Taxonomy=== | ===Proposed Keyboard Layout Taxonomy=== | ||
Latest revision as of 14:28, 2 July 2020
Keyboard Layout Taxonomy Proposal
Currently the keyboard layout is categorized by countries, which might not be suitable because it may bring following issues:
- Country flags (which may cause political problems)
- Not fair for the countries which are not in the list, e.g. Australia, New Zealand, Singapore, etc...
- Some layout is also available in certain countries but not recognized, e.g. Dvorak in China and India.
- Produce redundancy, like QWERTY in US, CN, IN are actually the same, but need to list 3 times.
- Some layouts, like EurKEY, do not belong to one particular country
Proposed Keyboard Layout Taxonomy
Use the keyboard layout itself as categories, such like:
- QWERTY-- Default
- ja_JP
- ko_KR,
- de_CH
- fr_CH
- it_CH
- en_UK
- EurKEY? (see discussion)
- ...
- DVORAK
- @lefthand
- @righthand
- QWERTZ
- de_CH
- @SunDeadKey
- @NOSunDeadKey
- @Mac
- fr_CH
- it_CH
- ...
- de_CH
- AZERTY
- fr_FR
- fr_BE
This taxonomy is more concise than countries-oriented. Users do not need to scroll the long countries list; and input method developers can easily have brief idea that what are they going to deal with.