For inputs on CrOS, there's a concept called "IME" which is actually a tight coupling of three orthogonal dimensions: "layout" - "input method" (IME) - "language model" (LM):

1/ Layout: Availability and spatial arrangement of keys. Defines repertoire of characters that can be typed directly. Arrangements tuned for ergonomic or specialised use cases, or simply a legacy.

2/ IME: Empower user to type things not directly present in the layout due to space constraint or linguistic technicality. Effectively expand the repertoire of characters.

3/ LM: Optional assistive technology to type correctly and efficiently in a language (e.g. Latin-based script languages), or necessarily merged with IME tier to form a "fuzzy IME" (e.g. for CJK).

Layouts, IMEs, and LMs are all named after languages/regions (e.g. where they originate from) but that doesn't necessarily mean the user must be typing in those languages, especially in the case of layouts.

The current coupling makes it confusing and less flexible for users. It'll also make UX for certain features hard-to-do or hacky-looking in future. Not sure if this is just an issue in the presentation layer (UI of the VK, system settings for both PK/VK), or an intrinsic architecture issue in the system.

Non-exhaustive list of examples:

"US keyboard":
layout = US/English QWERTY
IME = none
LM = English

"German - Swiss keyboard":
layout = Switzerland/German QWERTZ
IME = none
LM = German

"French - French keyboard"
layout = France/French AZERTY
IME = none
LM = French

"Pinyin input method":
layout = US/English QWERTY
IME/LM = Pinyin for Mandarin

"Vietnamese keyboard (Telex)":
layout = US/English QWERTY
IME = Vietnamese Telex
LM = none

(NB. Inconsistencies in the naming aren't covered by this bug, see crbug.com/889763 and crbug.com/889760 instead. Missing LMs aren't covered by this bug either).

 

For inputs on CrOS, there's a concept called "IME" which is actually a tight coupling of three orthogonal dimensions: "layout" - "input method" (IME) - "language model" (LM):

1/ Layout: Availability and spatial arrangement of keys. Defines repertoire of characters that can be typed directly. Arrangements tuned for ergonomic or specialised use cases, or simply a legacy.

2/ IME: Empower user to type things not directly present in the layout due to space constraint or linguistic technicality. Effectively expand the repertoire of characters.

3/ LM: Optional assistive technology to type correctly and efficiently in a language (e.g. Latin-based script languages: candidate suggestions, glide typing), or necessarily merged with IME tier to form a "fuzzy IME" (e.g. for CJK).

Layouts, IMEs, and LMs are all named after languages/regions (e.g. where they originate from) but that doesn't necessarily mean the user must be typing in those languages, especially in the case of layouts.

The current coupling makes it confusing and less flexible for users. It'll also make UX for certain features hard-to-do or hacky-looking in future. Not sure if this is just an issue in the presentation layer (UI of the VK, system settings for both PK/VK), or an intrinsic architecture issue in the system.

Non-exhaustive list of examples:

"US keyboard":
layout = US/English QWERTY
IME = none
LM = English

"German - Swiss keyboard":
layout = Switzerland/German QWERTZ
IME = none
LM = German

"French - French keyboard"
layout = France/French AZERTY
IME = none
LM = French

"Pinyin input method":
layout = US/English QWERTY
IME/LM = Pinyin for Mandarin

"Vietnamese keyboard (Telex)":
layout = US/English QWERTY
IME = Vietnamese Telex
LM = none

(NB. Inconsistencies in the naming aren't covered by this bug, see crbug.com/889763 and crbug.com/889760 instead. Missing LMs aren't covered by this bug either).