Last Comment Bug 780953 - Add language change event
: Add language change event
Status: RESOLVED DUPLICATE of bug 889335
:
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Makoto Kato [:m_kato]
Mentors:
Depends on:
Blocks: 841196 913712 876350
  Show dependency treegraph
 
Reported: 2012-08-07 11:47 PDT by Gregor Wagner [:gwagner]
Modified: 2014-05-25 17:53 PDT (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
Make navigator an Event Target (10.99 KB, patch)
2013-06-01 04:01 PDT, Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
bugs: review-
Details | Diff | Splinter Review
Listen for intl.accept_languages changes (4.37 KB, patch)
2013-06-01 04:03 PDT, Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
no flags Details | Diff | Splinter Review

Description Gregor Wagner [:gwagner] 2012-08-07 11:47:45 PDT
Many apps for B2G need access to the mozSettings API just to get notified when the language changes. We should fix this. We need something like a mozlanguagechange event.
Comment 1 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-08-07 11:54:30 PDT
Apparently navigator.language is supported across multiple browsers, including Gecko.

So we should simply fire an event on the navigator object called "languagechange" whenever the language changes. And add a navigator.onlanguagechange property. But do note that we should make sure that navigator is a proper EventTarget object so that you can write navigator.addEventListener("languagechange", function() {...}) as well
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-08-07 12:05:06 PDT
I think this should block, because without this notification we're forced to hand out settings privileges to *every* localized app to avoid rebooting on language changes, which is ridiculous and a false dichotomy.

Objections?
Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-08-10 10:01:48 PDT
While I agree that it sucks that we'll have to hand out more permission than we otherwise would, i don't think that we'd hold the release for this.
Comment 4 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2012-08-10 10:06:14 PDT
Was in triage, and I think I agree with Comment 2 and wish we'd plused this.

Settings permissions seems like an awfully sensitive thing to have to give out to all localized apps, especially in an international market where I assume most major apps will be localized.

From a user point of view, I'd be concerned that random apps wanted settings access, but perhaps also confused when I had to reboot/restart apps after changing languages. The latter would particularly be true if some apps changed and others didn't, though I suppose that could happen with the event as well.
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-08-10 12:49:14 PDT
Note that we won't be handing out settings permission to 3rd party apps. The situation is a bit worse there in that they will either have to poll this property, or they simply won't switch language until the user restarts the app. I think that's ok behavior to ship v1 with. Switching language isn't a terribly common thing to do and most apps likely won't implement dynamic switching even if we provide the hooks to let them do it.

Note that Firefox Desktop requires restart in order to change language.
Comment 6 Fabien Cazenave [:kaze] 2012-08-10 15:13:28 PDT
(In reply to Jonas Sicking (:sicking) from comment #5)
> Switching language isn't a terribly common thing to do

It’s just nice to have, especially for our l10n contributors or for the “First Run Experience”: it would allow us to ask for the preferred language without restarting the phone.

> and most apps likely won't implement dynamic
> switching even if we provide the hooks to let them do it.

At the moment, all apps have to wait for the 'localized' event to display the content of <body> and initialize their UI. If we had such a 'mozlanguagechange' event, the l10n.js lib could fire a 'localized' event when 'mozlanguagechange' is detected, which basically implies that every internationalized app should be dynamically switchable by default.
 
> Note that Firefox Desktop requires restart in order to change language.

If this event is an easy thing to implement I think we should do it, otherwise I agree we could live without it — especially for a v1.
Comment 7 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-08-10 15:40:40 PDT
I agree it's a nice-to-have, but not something we'd hold the release for. That means it's not a blocker no matter how easy it is to fix.

But that doesn't mean we wouldn't accept a patch!
Comment 8 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-08-10 17:06:35 PDT
Talking this over with gwagner and smaug, I think this is what we want to implement:
* add a pref observer for intl.language to ContentParent (http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp)
* this observer sends an IPDL message (http://mxr.mozilla.org/mozilla-central/source/dom/ipc/PContent.ipdl) to the child
* the child (http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentChild.cpp) receives this message and iterates over its list of managed PBrowserChild actors (ManagedPBrowserChild), casting them to TabChild* and calling a new method on each of them
* this method obtains a window from TabChild::mWebNav, creates a 'localized' event (something like http://hg.mozilla.org/mozilla-central/file/b5ae446888f5/content/base/src/FileIOObject.cpp#l109) and dispatches it to the window obtained earlier

That covers all content processes. We may need to do something in the parent process as well, but this would be a good start.
Comment 9 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-08-10 17:11:33 PDT
From IRC, relevant to "obtains a window from TabChild::mWebNav":

20:10 <smaug> do_GetInterface gives you nsIDOMWindow, which you can QI to nsIDOMEventTarget
20:10 <smaug> do_GetInterface(WebNavigation())

nsIDOMEventTarget has DispatchEvent.
Comment 10 Olli Pettay [:smaug] 2012-08-10 17:19:26 PDT
But IMO making navigator an event target and dispatching event there would feel more natural.
Comment 11 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2012-08-13 14:41:18 PDT
If this doesn't hit 3rd party apps, then I agree re: nice-to-have vs. blocker, and back off my objection.
Comment 12 Mounir Lamouri (:mounir) 2012-08-14 02:37:08 PDT
I thought the permission scheme we wanted to have for the Settings API was to allow read access to some properties trough different permissions (same thing for write access). That way, we could have "locale" being readable with "setting-rea-l10n". Other examples would be "settings-wifi" to have read/write access to wifi settings for a wifi manager app.
Comment 13 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-08-14 09:06:03 PDT
First I've heard of that.  Mark me down as not in favor of that approach :).
Comment 14 Gregor Wagner [:gwagner] 2012-08-14 09:28:19 PDT
(In reply to Mounir Lamouri (:mounir) from comment #12)
> I thought the permission scheme we wanted to have for the Settings API was
> to allow read access to some properties trough different permissions (same
> thing for write access). That way, we could have "locale" being readable
> with "setting-rea-l10n". Other examples would be "settings-wifi" to have
> read/write access to wifi settings for a wifi manager app.

We don't plan it that fine-grained. We are implementing a "settings" permission with access types "read" and "readwrite" but we don't add permissions per setting.
Comment 15 Mounir Lamouri (:mounir) 2012-08-16 03:22:24 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #13)
> First I've heard of that.  Mark me down as not in favor of that approach :).

That's one of the solutions that was proposed during the security review:
https://wiki.mozilla.org/Security/Reviews/SettingsAPI

So, if I want to allow "Foobar WiFi Manager" to modify WiFi settings, I will have to give that application readwrite access to *ALL* my settings?
Comment 16 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-08-16 03:46:26 PDT
For now the settings API is only exposed to certified apps. So we don't support writing the FooBar Wifi Manager app. We should be able to do better with time, but I'd rather not spend time debating that right now, we have plenty of other things to worry about for v1.
Comment 17 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-08-16 10:22:49 PDT
(In reply to Mounir Lamouri (:mounir) from comment #15)
> So, if I want to allow "Foobar WiFi Manager" to modify WiFi settings, I will
> have to give that application readwrite access to *ALL* my settings?

Agree with Jonas, but it's just not this clean in general.  And when the wifi manager needs to know about airplane mode?

We haven't even begun spec'ing settings, let alone isolated security groups ...
Comment 18 Lucas Adamski [:ladamski] 2012-08-16 23:31:26 PDT
Agreed, I think we have our hands full as-is.
Comment 19 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2013-06-01 04:01:53 PDT
Created attachment 756953 [details] [diff] [review]
Make navigator an Event Target

The patch turns the navigator object into an event target
Comment 20 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2013-06-01 04:03:41 PDT
Created attachment 756954 [details] [diff] [review]
Listen for intl.accept_languages changes

I'm not 100% sure who is the best reviewer for this.
Comment 21 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2013-06-01 04:04:15 PDT
I will add some tests as well if the approach sounds good.
Comment 22 Olli Pettay [:smaug] 2013-06-03 02:00:42 PDT
Has anyone brought this up in whatwg? I'd really prefer not adding moz prefixed onfoo handler.
Comment 23 Olli Pettay [:smaug] 2013-06-03 03:00:59 PDT
Comment on attachment 756953 [details] [diff] [review]
Make navigator an Event Target

  // nsIDOMEventTarget
>+  NS_FORWARD_NSIDOMEVENTTARGET(nsDOMEventTargetHelper::)
NS_REALLY_FORWARD_NSIDOMEVENTTARGET

>+  Navigator(nsPIDOMWindow *aInnerWindow);
nsPIDOMWindow* aInnerWindow


Why you remove that Invalidate() call? That is rather major change and shouldn't be
related to this.

You should be able to get rid of mWindow from Navigator, since nsDOMEventTargetHelper (aka DETH)
has GetOwner();
Navigator::GetWindow() becomes also useless.

But, SetWindow is interesting. It is called when we reuse document. Navigator is bound to a new
inner window. I think we should rebind the DETH to that new inner window, so that event listeners
still work after document.write
(and I do hate document.write)
Comment 24 Mounir Lamouri (:mounir) 2013-06-13 14:04:15 PDT
Comment on attachment 756954 [details] [diff] [review]
Listen for intl.accept_languages changes

Review of attachment 756954 [details] [diff] [review]:
-----------------------------------------------------------------

In addition of the comments below, you should also add nsIObserver in the NS_INTERFACE_MAP.

I have another larger issue: what is the advantage of that solution compared to the polyfill currently in Firefox OS? Is there any benefits in trying to land this ASAP instead of waiting for a consensus?

And sorry for the delay, I was off the last 10 days.

::: dom/base/Navigator.cpp
@@ +1636,5 @@
> +Navigator::Observe(nsISupports *aSubject,
> +                    const char *aTopic,
> +                    const PRUnichar *aData)
> +{
> +  if (!strcmp(NS_PREFBRANCH_PREFCHANGE_TOPIC_ID, aTopic)) {

nit: you can also do:
if (strcomp(..., ...)) {
  return NS_OK;
}

// Other case.

@@ +1637,5 @@
> +                    const char *aTopic,
> +                    const PRUnichar *aData)
> +{
> +  if (!strcmp(NS_PREFBRANCH_PREFCHANGE_TOPIC_ID, aTopic)) {
> +    nsCOMPtr<nsIPrefBranch> prefs (do_QueryInterface(aSubject));

nit: this is easier to read:
nsCOMPtr<nsIPrefBranch> prefs = do_QI(aSubject);

@@ +1638,5 @@
> +                    const PRUnichar *aData)
> +{
> +  if (!strcmp(NS_PREFBRANCH_PREFCHANGE_TOPIC_ID, aTopic)) {
> +    nsCOMPtr<nsIPrefBranch> prefs (do_QueryInterface(aSubject));
> +    NS_ASSERTION(prefs, "Bad observer call!");

MOZ_ASSERT()

@@ +1642,5 @@
> +    NS_ASSERTION(prefs, "Bad observer call!");
> +
> +    NS_ConvertUTF16toUTF8 pref(aData);
> +
> +    if (pref.EqualsLiteral(INTL_ACCEPT_LANGUAGES)) {

I guess you can as well do:
if (NS_ConvertUTF16toUTF8(aData).EqualsLiteral(...)) {

@@ +1643,5 @@
> +
> +    NS_ConvertUTF16toUTF8 pref(aData);
> +
> +    if (pref.EqualsLiteral(INTL_ACCEPT_LANGUAGES)) {
> +      this->DispatchTrustedEvent(NS_LITERAL_STRING("mozlanguagechanged"));

this-> isn't needed here.
Comment 25 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-06-21 18:28:35 PDT
I agree, it'd be great to avoid using moz prefixing here.

Olli: could you help with bringing this up on the appropriate list? I'd prefer not to do that on WHATWG since Hixie has a huge backlog and it'll take a long time to get anything actually accepted into a draft.

But I'm happy to defer to you. Especially if you help with actually bringing this to whatever list is the right one :)
Comment 26 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-07-15 15:47:49 PDT
Marcos: I believe you were driving a conclusion here?
Comment 27 Zibi Braniecki [:gandalf][:zibi] 2013-07-15 16:00:21 PDT
It is related to bug 889335
Comment 28 Marcos Caceres [:marcosc] 2013-07-17 09:35:36 PDT
Jonas, I raised this on the W3C bugzilla a few months ago: 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21290
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21289

But there has been no movement there.
Comment 29 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-07-20 16:44:10 PDT
The best way to get traction is probably to let hixie know that we're interested in shipping something like this sooner rather than later. That'll usually get his attention to get it considered for the whatwg version. Once it gets in there it'll get into the w3c version as well.
Comment 30 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-07-20 16:46:10 PDT
Alternatively, if no one provides feedback on whatwg, we could write up a semi-formal spec and send links to it on both the whatwg and w3c lists. At least at that point we pass the spec-test which should allow us to implement.

Much better is of course if other browsers express interest in implementing.
Comment 31 Marcos Caceres [:marcosc] 2013-07-23 05:47:55 PDT
(In reply to Jonas Sicking (:sicking) from comment #30)
> Alternatively, if no one provides feedback on whatwg, we could write up a
> semi-formal spec and send links to it on both the whatwg and w3c lists. At
> least at that point we pass the spec-test which should allow us to implement.

That sounds good. However, we are still working out the details. I think we've made good progress in the other bug in getting a more clear understanding of what we need. However, there are still core bits missing with regards to the event IMO. 

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=889335#c49 


> Much better is of course if other browsers express interest in implementing.

Yep.
Comment 32 Marcos Caceres [:marcosc] 2013-07-24 04:12:37 PDT
Started working on proposal. Should hopefully have a it spec'ed by end of today or sometime tomorrow.
Comment 33 Marcos Caceres [:marcosc] 2013-07-25 09:57:58 PDT
Ok, I've put together a proposal. Sorry it's a bit long, but would appreciate any feedback before I send it to the WHATWG. Please respond with comments inline. 

A gist is also available: 
https://gist.github.com/marcoscaceres/3f72a0324df9aedcbec5


# Proposal: `navigator.languages` API

## Abstract

This document proposes an extension to HTML's `Navigator` interface to enable
dynamic localization of content. The idea is to expose to script the language
tags that represents the user's locale preferences (akin to the language tags
that are normally sent with HTTP's `Accept-Languages` header).

Also proposed is a "`languageschange`" event, so that scripts can be notified if
the user changes the ordering of their preferred locales.

## Problem we are trying to solve

In order to support dynamic localization of content on the client-side,
developers need to have access to the user's locale  preferences. In user
agents, this is generally represented as an ordered list  of [BCP47] language
tags, which is shared with servers through the `Accept-Languages` HTTP header.

Traditionally, to access this list of language tags developers need to query a
server to tell them what the browser's language preferences are set to (i.e., by
reflecting the `Accept-Languages` HTTP header - and usually stripping away the
"q" values).  This has led to the creation of various xhr-based hacks and
workarounds on the client side. See: [JavaScript for detecting browser language
preference](http://stackoverflow.com/questions/1043339/javascript-for-
detecting-browser-language-preference) .

There are a number of issues with this work-around:

 * because of the reliance on making a HTTP request, the values are not
immediately available to script.

 * because of the reliance on making a XHR-based request, this becomes
impractical if the user is not connected to the network.

 * because of the reliance on HTTP requests, it's not possible to immediately
know if the user's preferred language order has changes (even though it is
rare - FireFox applications rely on this to be able to maintain the UI localized
without needing to reboot the device).

To overcome these limitations, and solely in Mozilla's FirefoxOS, developers are
relying on a  proprietary 
[mozSettings API](https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSettings) 
to get notified when the user's locale preferences change.

In order to address the issues described above, and to move away from having to
rely on a proprietary solution, this document proposes the following extensions
to the [HTML]'s Navigator interface.
 
## Extensions to Navigator interface

```WebIDL
partial interface Navigator : EventTarget {
   readonly attribute DOMString[]  languages;
            attribute EventHandler onlanguageschange; 
}
```

## The `languages` attribute

When getting, the languages attribute returns a read only platform Array
[WebIDL] of  valid language tags in canonical form [BCP47]. The array is ordered
from most preferred to least preferred, where the first item is the language tag
that represents the user's most preferred language.

## Event handlers

If the user updates their locale preferences in such a way that it would cause
the ordering of language tags change, then the user agent MUST perform the
following steps:

1. Let lang list be the updated list of preferred locales.

2. Queue a task to perform the following:

2.1 If the first item of the lang list is not the same value as the value of
the 'navigator' object's `language` attribute, update the `navigator` object's `
attribute` to be the first item lang list.

2.2 Update the values of `navigator`'s `languages` attribute so they are the
same as those in lang list.

2.3 Fire a simple event named "`languageschange`" at the `navigator` object.

The task source for these steps is the DOM manipulation task source.

### Acquiring the languages

The end-user's locale preferences represents the end-user's preferred languages
and regional settings, which are derived from the operating system or directly
from the user agent. As there are numerous ways a user agent can derive the end-
user's preferred languages and regional settings, the means by which those
values are derived are beyond the scope of this document and left up to the
implementation.

## Privacy considerations

As with navigator.language, there are privacy implications in exposing the
user's language preferences, as it can potentially be used to infer both the
physical location (to at least a country level) and potentially the user's
ethnic background (in those that choose have explicitly selected more than one
language preference). These values can also be exploited, together, with other
data to uniquely identify users.

However, these values are already shared with servers with every HTTP request,
thus this API does not exacerbate the finger-printing situation.

Regardless, implementers are encouraged to reflect the value of
navigator.language unless the user has explicitly indicated that the site in
question is allowed access to the information.

## Known usability issues

It is envisioned that the primary purpose for this API will be to take a list of
language-tags supported by an application and compare it with the list of
language-tags that represent the user's locale preferences.

Because of the nature of language tags, working with language tags can be
notoriously difficult - particularly when comparing two lists for changes.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=889616

To make this API useful in practice currently requires a supporting i18n library
(e.g., [Mozilla's L20n: Localization 2.0 library ](https://github.com/l20n/l20n.js)). 

To make it possible to use this API on its own, Mozilla is discussing with TC-39
the possibility of exposing the LookupSupportedLocales and
CanonicalizeLanguageTag abstract algorithms as part of an extension of
[Ecma-402].


## References
[BCP47] 
 - [Tags for Identifying Languages](http://tools.ietf.org/html/bcp47)
[Ecma-402]
 - [ECMAScript® Internationalization API Specification ](http://www.ecma-international.org/ecma-402/1.0/ECMA-402.pdf)

## Related Mozilla bugs

The following bugs motivated Mozilla to put together this proposal. The use
cases are have mainly been driven by FirefoxOS, though they've also come up
else where (e.g., in with Firefox Extensions).

* [bug 889335 - navigator.languages](https://bugzilla.mozilla.org/show_bug.cgi?id=889335)
* [Bug 780953 - Add language change event](https://bugzilla.mozilla.org/show_bug.cgi?id=780953)
* [Bug 889617 - Provide API for user requested language fallback](https://bugzilla.mozilla.org/show_bug.cgi?id=889617)
* [Bug 288670 - Use intl.accept_languages to choose the locale for a package if the current locale is unavailable](https://bugzilla.mozilla.org/show_bug.cgi?id=288670) 
* [Bug 562648 - Prioritized locale list for fallback of strings or add-ons](language/translation fall-back; fallback is always en-US)]
Comment 34 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-07-25 14:18:38 PDT
Sounds good to me. Though we need to figure out the frozen array/DOMStringList/whatever issue. But that's orthogonal.
Comment 35 Zibi Braniecki [:gandalf][:zibi] 2013-07-25 15:40:58 PDT
looks good to me
Comment 36 Mounir Lamouri (:mounir) 2013-07-26 09:32:33 PDT
Sounds good to me. Thank you for working on that Marcos :)
Comment 37 Marcos Caceres [:marcosc] 2013-07-30 11:18:32 PDT
Quick update: 

 * spec is now here: https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md

 * I emailed both the WHATWG and i18nWG. Got lots of great feedback from i18nWG - none from WHATWG yet. 

Will try to address i18nWG feedback tomorrow before I go on (un)PTO.
Comment 38 Zibi Braniecki [:gandalf][:zibi] 2013-10-02 15:23:20 PDT
Any progress on this?
Comment 39 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-10-03 23:12:55 PDT
Olli, is this something you could have a look at? This seems quite simple to implement and would help B2G a lot.
Comment 40 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-10-03 23:15:56 PDT
Masatoshi, this might also be something that'd interest you? It would really be awesome to have fixed.
Comment 41 Marcos Caceres [:marcosc] 2013-10-04 08:04:53 PDT
The spec was vetted by the W3C i18n WG (they liked it), but I got no feedback from the WHATWG. When implemented, please add this somewhere Mozilla specific so it doesn't interfere with the platform (or just make it a firefox os specific thing).
Comment 42 Jonas Sicking (:sicking) No longer reading bugmail consistently 2013-10-09 23:37:52 PDT
It seems very silly to do something mozilla specific here :(

Can we try to figure out if other browser vendors simply aren't interested in this use case. Or if they didn't have the bandwidth to review the proposed solution.

If they aren't interested in solving this problem at this time, then I believe our proposed prefixing rules allow us to expose it unprefixed as long as we try to make the cross-browser implementable and write up a specification.
Comment 43 Andrew Overholt [:overholt] 2013-10-11 13:39:24 PDT
(In reply to Jonas Sicking (:sicking) from comment #42)
> It seems very silly to do something mozilla specific here :(
> 
> Can we try to figure out if other browser vendors simply aren't interested
> in this use case. Or if they didn't have the bandwidth to review the
> proposed solution.
> 
> If they aren't interested in solving this problem at this time, then I
> believe our proposed prefixing rules allow us to expose it unprefixed as
> long as we try to make the cross-browser implementable and write up a
> specification.

Correct (and they're just guidelines, not hard-and-fast rules).  I'll email some Blink contacts to see if I can get some feedback.
Comment 44 Marcos Caceres [:marcosc] 2013-10-14 14:27:13 PDT
Sent out another ping to the WHATWG: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041093.html
Comment 45 Marcos Caceres [:marcosc] 2013-10-19 07:41:27 PDT
Hixie seems to like the proposed solution + Erik Arvidsson that works on Chromium also gave it an ok. 

Tracked in WHATWG by:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517
Comment 46 Hixie (not reading bugmail) 2014-02-04 11:38:10 PST
Spec now has a 'languagechange' event that fires at the global object (also in workers), and a <body onlanguagechange> handler for convenience. http://html5.org/r/8458
Comment 47 Staś Małolepszy :stas 2014-05-21 05:44:14 PDT
A 'languagechange' event landed as part of bug 889335.  See https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage.languages

Can this bug be closed now?
Comment 48 :Ehsan Akhgari 2014-05-25 17:53:55 PDT
Yes!

*** This bug has been marked as a duplicate of bug 889335 ***

Note You need to log in before you can comment on or make changes to this bug.