This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The KeyboardEvent.locale property is underspecified. BCP-47 is too general, we need to get much more crip on what sub-set of these strings are reasonable and which are not. Eg., there is a dvorak BCP-47 string. Should this be reported? Goal should be to simplify the set.
It's good timing. I tried implementing KeyboardEvent.locale and CompositionEvent.locale on Gecko. Then, I worked on Windows and Mac. I think there is no API on Linux (except directly accessing IM framework such as iBus, SCIM). I'm still investigating about Android, though. On Windows, we can make conversion table with: http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx # I guess that IE 9 also used this table. On Mac, we can get the language property of current TIS with kTISPropertyInputSourceLanguages. https://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html Then, on Mac, we cannot return locale. E.g., cannot return en-US, can just return en. And IE 10 returns "zh-CN" for simplified Chinese. However, on Mac, we can returns "zh-Hans". So, I have no idea to implement with good compatibility between platforms. So, I'm now thinking that .locale is not useful for web developers under current spec.
The draft patches for Gecko are here: https://bugzilla.mozilla.org/show_bug.cgi?id=680832
We may want to move KeyboardEvent.locale into UI Events so that we can take the time to define it properly. Nothing in D3E relies on KeyboardEvent.locale, but UI Events has a few methods that want to make use of it.
The locale attribute has been moved into UI Events.
Now tracking as: https://github.com/w3c/uievents/issues/14