Re: proposal: add input/keyboard locale to text and keyboard events [ISSUE-119]

For the text direction use case, the input locale is highly likely to
correspond to the actual text being written. For example, when the Hebrew
keyboard is in use, it is only possible to type uppercase Latin-script
letters, so in the vast majority of cases the user switches to the English
keyboard for English text.

For the smart-quotes use case, it is important to note that the whole
feature is a heuristic, and complete correctness is not required. An
application using this approach should really allow the user to specify the
document language explicitly (as well as turn smart quotes off completely).
Nevertheless, when the user does not specify the language - and one would
have to presume that this will be case most of the time - the input locale
is a higher-quality signal than the other possibilities: the system user
interface language, the browser user interface language, and the language
setting for the HTTP request. (Not that the browsers actually expose all of
these.) For monolingual (and 1.5-lingual, i.e. write in only one language)
users, all of these signals as well as the input locale are highly likely to
have the same value. For bilingual users, however, the keyboard locale has a
good chance of being changed when the user starts writing in a different
language, while the other signals most certainly don't.

It is worthwhile adding that Microsoft Word, the most widespread word
processor, uses keyboard language for both of the use cases given.

Aharon