Input Language Status

language-menu.png

We want to provide a clear indication of what the current input language for the system is. We also want to provide a quick and easy way to switch between a few previously used language options.

Discussion

Essentially what is to the user an input language selection is actually a superset of the keyboard layout selection (from Xorg) and the input method selection (from iBus).

Note, that since text prediction for on screen keyboards may also use the Input Method framework we may have to account for them in some way.

Since the goal of the status indicator is to differentiate the options in the small pool of languages used by the user, the identification key does not have to be globally unique. It should be unique and recognizable within the switch group.

We should try to stay as close as possible to the user's mental model of the system. The user's model and goal is primarily that of switching between languages - or where that is ambiguous, script name.

Guidelines

  • The system should not leak implementation details to the user
  • Each option will have a two character ID field and a slightly longer (<25 char) Name field

  • The ID field should be displayed in the top bar status indicator
  • The ID and Name fields should both be displayed in the associated menu for the status indicator
  • Simple keyboard mappings should use the ISO_639-1 language code for the ID field (in lower case)
  • Keyboard mappings that do not have ISO_639-1 language code should use a unique 2 character ID with the first character capitalized (Eg. Dvorak = Dv)
  • Input methods with multiple variants per language should use a different character from the relevant script as the ID
    • A symbol that helps identify the type or technique of the method should be preferred.

Open Questions

  • How do we handle things like shifts_toggle for layouts like ru that are actually "ru,us"?
    • svu: The layout is always single-group, since long ago. So 'ru' is never 'us,ru' - at least we do not have to support that insanity. User actually has to choose 2 layout to get 2 groups.

Comments

mclasen

Would be good if the menu gave a hint that this is keyboard related, not UI language. Might be enough to just have the word keyboard appear, eg 'Show keyboard layout'.

Since this is supposed to be a combined keyboard layout/input method indicator, the 'Preferences' item will have to bring up a new, combined keyboard/input method preferences dialog, or something like that.

I think it is common to switch input methods, but keep the keyboard layout the same. How will that work ? I guess there will have to be some way for the user to name layout/input method combinations, or the system needs to be smart enough to come up with unique names and abbreviations on its own.

svu

  • Using non-translated ISO codes is a very bad idea IMHO. Currently the indicator am using 3-char "short descriptions" from (xkeyboard-config)base.xml which are based on ISO codes (3166-3) - but they are translatable.
  • It would be highly non-trivial to manage the configurations where different technologies are mixed: US (XKB) + RU (XKB) + CN (IBUS). Provide transparent switching between them etc.
  • The xkb "layout options" would not affect IBUS layouts. That might confuse people

So, making transparent use of two technologies which are SO different (ibus being on higher level than xkb) would be quite non trivial. Should we talk about some kind of abstraction layer?

mclasen

Sergey, I think the expectation of this design is that you would most likely have a certain xkb configuration per language, and a certain input method configuration per language, but probably only one of each, so selecting language XYZ would give you the default xkb configuration and input method configuration for that language. The preferences will then allow you to adjust your keyboard configuration for language XYZ, as well as your input method for that language.

svu

Jon, "one of each" is a very bad, very user-unfriendly idea for XKB. There are multiple variants for most of languages - and for a good reason. Just think of English language, for example - which one would you choose, US or UK or ... ? ;)

  • mccann: What you are looking at in this menu are language/layout combinations that the user has already selected. Of course the system may support various layouts for English but I consider it very unusual to switch between multiple alternate layouts in the same language. For example switching between UK and US would be unusual. In the case where it does occur you can just provide enough information to disambiguate the menu items. The System Settings panel where you select new languages would of course be unambiguous.

    • svu: I agree. My point is that when user chooses one layout 'ru', he does not get layout 'us' for free - without explicitly asking for it.

I do not quite understand some aspects:

1. Do you plan to allow user to choose IBus for US layout and XKB for ru(typewriter)?

2. If layouts are identical in XKB and IBUS - how would you explain to the user why he has to make a choice?

  • mccann: the user should not have to know anything about ibus or xkb.

    • svu: I agree - these terms are technical and should not be exposed. But I do not know how explain that for some Asian language you can choose "THIS" or "THAT" way to input characters? Especially considering the fact that ibus is built on top of XKB, so if you chose improper XKB layout(s), ibus input may break...

svu

So far, we have more questions than answers in relation to xkb-ibus integration. Should we think about some Plan B for April 2011?

  • mccann: I'd love to see a plan of any kind.

    • svu: For a moment, the only idea I have is to port existing indicator to gnome-shell (no matter how I dislike JS). That's technically possible. I do not have a plan on how to integrate xkb with ibus. Does anybody know who would be the ibus person to talk to? I tried to ask them at Google groups and on IRC - no feedback...

juhp: Apologies for never chiming in earlier (I finally made a new wiki a/c since I couldn't recover my old one...).

Takao Fujiwara is working on ibus xkb and gnome-shell integration: see for example https://fedoraproject.org/wiki/I18N/InputMethods#GNOME-Shell and https://github.com/fujiwarat/ibus-gjs. Some of this work is already in Fedora 15 and more coming to Fedora 16. (I think ibus-xkb was a first attempt at providing some form of xkb support from ibus, but core ibus ifself now has support for xkb layout switching.)

See Also

Design/OS/InputLanguageMenu (last edited 2015-06-25 09:52:13 by AllanDay)