Bug 27555
| Summary: | Expose the Accept-Language list as window.navigator.acceptLanguages | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jungshik Shin <jshin> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Enhancement | CC: | aa, ap, dylan, erikkay, mjs, nickbaum, xji |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Jungshik Shin
Currently, the UI language of a browser is exposed via window.navigator.language. Some "clients" need to access the value of Accept-Language the same way ( window.navigator.acceptLanguages). See http://crbug.com/14574
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jungshik Shin
sorry for bug spams.
Alexey Proskuryakov
It would be great to simplify localization for Web applications, if that's the rationale for adding this feature to the Web platform, and not just as an extension for Chromium plug-ins.
But it is not obvious whether exposing accept-language is the way to do it. This really looks like a topic for whatwg discussion to me.
Aaron Boodman
The use case we had in mind was actually translation. If we had the accept languages of the browser available to JavaScript, it could be implemented as Chrome extension.
This seems like a reasonable thing to explain through the web platform, but I agree it should also get brought up on whatwg.
Dylan McCall
Since https://bugs.webkit.org/show_bug.cgi?id=163220, this information is available through the window.navigator.languages property (https://html.spec.whatwg.org/#navigatorlanguage), so I believe this can be closed.
Alexey Proskuryakov
In WebKit, window.navigator.languages is just an array with one element, so it doesn't add anything new that window.navigator.language didn't provide.
That said, Accept-Language has been simplified accordingly too, so this feature would be pointless.