User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
In some websites, there are forms to be filled by the end-user.
In multilingual contexts, some developers try to change the input language of the keyboard or hook to the field that should be filled in another language, detect keystrokes in English and replace it with the characters of the target language.
Is it a good practice in user experience?
Has any kind of study been made on this?
No, don't do such a thing automatically. It goes against two very important principles of usability: don't surprise the user, and let the user feel in control.
Typing in a different language is a problem users have to solve in many situations. Therefore, everybody who has to type in a second language has already chosen an application-independent solution which works for him. Automatically replacing this solution with your own homebrew one is bad.
First problem: The user may not want to type (everything) in the language you think he should be typing in. Example: a user writes in his native, non-latin written language, The French word for book is "livre". If you transliterate all keyword strokes automatically, the French word will get transliterated too, rendering it impossible to convey the information as the user intended it.
Second problem: You don't know what keyboard layout the user is accustomed to. Yes, there tends to be one "standard" layout per country, but it is not always the most widely used. Especially young computer users who never sat at a typewriter and don't want to learn two layouts for typing their language and typing latin symbols will frequently prefer to use a phonetic layout over their country-standard layout. But phonetic layouts are not always standardized. Especially for letters which don't have an equivalent in English, there can be keystroke combinations instead of single key presses. And some users have learned over years of typing their language in transliterated latin to use some unusual key combinations to express letters. Consider the Cyrillic letter щ. I know following variants of entering it among native Bulgarian speakers: as sht, scht, w, 6t and ]. A Russian will probably enter other combinations stemming from mappings of the Russian pronunciation of the letter to his first foreign language, starting with shch and schtsch, plus others which can have become common for obscure reasons. And if somebody's first Cyrillic-script language is Russian, he will probably prefer to enter Bulgarian using a Russian layout too, because a Bulgarian layout will be as strange to him as Dvorak is to a Qwerty user. So, choosing a standard layout based on the language for the input field is a terrible idea.
Third problem If the user already has a solution in place, your solution will interact with it in unforeseen ways. For example, I had a time when I used a Firefox plugin for transliteration, when I pressed F2 in a field, it switched my keyboard layout to a customized Cyrillic one. I can't predict how your automated solution would behave in this case, but if it overrode the existing one, it would be first very disorienting. If in my custom layout, the ? key prints _ (mine did, because I needed a combination of phonetic Cyrillic with Qwertz non-letter characters), and yours prints ?, I'd be very surprised at first, and probably suspect a bug in my transliteration addon instead of a website hijacking the transliteration functionality. If I find out what is happening, I would be very annoyed at not being able to use my custom solution. Even if the user goes the more usual route of installing a second keyboard layout on the OS and changing keyboard layout for the current window with a keyboard shortcut, you changing it for him on the input field level will be surprising and disorienting, he will think that he has switched when he didn't, and so on.
That being said, providing the option to switch the layout manually is a good thing. First, it avoids both of the worst problems with the automatic solution: surprise and loss of control. Second, while a solution the user has in place will always be as good as or superior as yours, the user may not have a solution in place right now. Maybe he is sitting at a friend's computer. Maybe it is his work computer where he isn't allowed to change the system settings. Maybe he is desperately trying to get an old Windows 2000 system to work and doesn't want to take care of details such as installing a keyboard layout. Maybe he is using the newest Gnome, which tends to break the keyboard layout switching shortcut each other version. Whatever the reason, you can do it similar to Google translate and offer a virtual keyboard layout switcher which works independently of layouts already installed on the system, preferably with a schema of the active layout which can be used at least as a reference, in the ideal case also as a virtual keyboard.
You can go with the approach used in log-in screens. For instance, when you log in to windows, and your CAPS LOCK is on, a little ballon draws your attention to this fact when you focus the field. This relies on the assumption that you usually don't want your CAPSLOCK on when you type in your password. In a similar manner, when you expect a field to be entered in a certain language, but you detect the keyboard is set to another, you can simply draw a little attention to this fact (without interfering with filling the field, of course).
Picture taken from: http://www.humanized.com/weblog/images/caps_lock_indication.png
From a personal perspective, I once stumbled in an Israeli government website which required me to fill a form. Most of the fields there needed values in Hebrew. Their solution was to translate every English keystroke into the correlating Hebrew one (assuming all users are using the regular QWERTY layout). I must admit I was delighted by this automatic experience, even though @Rumi P. has raised valid points against it.
