proposal: add input/keyboard locale to text and keyboard events

Pierre Cadieux, Hirinori Bono and I would like to propose the following i18n
addition to the TextEvent and KeyboardEvent DOM3 interfaces:

A new property indicating the locale of the keyboard or other input device
using which the input was generated.

In both event types, this should be a string (e.g. "en-US"), and can be null
when unknown (e.g. when the input method is paste). In the TextEvent
interface, the new property could be called inputLocale. In the
KeyboardEvent interface, it could be called keyboardLocale or perhaps just
locale.

Use case 1: smart quotes in script-based online editor / word processor.

Different languages use different opening and closing quotation mark
characters (e.g. U+201C (“) and U+201D (”) in English, U+00AB («) and U+00BB
(») in French, and U+201E („) and U+201C (“) in German), but their standard
keyboards rarely allocate keys for them. Thus, word processors typically
implement a "smart quote" feature that replaces ASCII quote characters typed
by the user with the opening and closing quotation marks appropriate for the
document language. Since users rarely want to bother setting a document
language, and can use different languages in a single document, word
processor programs often the keyboard language as the basis for deciding
which quotation marks to use. This is currently not possible for online
editors, since they do not know which keyboard is being used to generate
input.

Use case 2: text direction in script-based online editor / word processor.

Hebrew, Arabic, Farsi, and other languages are written right-to-left.
However, it is common for right-to-left documents to contain some
left-to-right words (e.g. acronyms like "HTML"), phrases (like the title of
a foreign-language article), and paragraphs (like an extended quote from a
foreign-language article). Although the Unicode Bidi Algorithm provides a
default way to display a mixture of left-to-right and right-to-left text
without explicit indication of a paragraph's direction, or where the text
direction inside a paragraph changes or reverts, this is heuristic and often
insufficient to display bidi text as intended. Full-featured word processors
(online and otherwise) therefore typically allow the user to indicate the
paragraph direction using a UI control. However, the user experience of
having to both click on the direction control and change the keyboard
language when needing to switch between different-direction languages is
problematic, since users very often forget to do one or the other. It is
therefore desirable for a word processor to provide a reasonable default for
paragraph direction based on the direction of the first character entered by
the user. To allow the same approach for paragraphs that begin with numbers,
neutral characters, and whitespace, however, what one really wants is an
indication of the language of the keyboard (or other input method) used to
generate the first character. The same technique is even more useful for
direction changes inside a paragraph, since word processors rarely provide
an explicit means of indicating them, and they often need to begin with a
number or end in punctuation (e.g. closing a parenthetical expression begun
in the middle of the opposite-direction phrase) - examples of cases where
the Unicode Bidi Algorithm does not do a good enough job.

Aharon Lanin