Bug 27555

Summary: Expose the Accept-Language list as window.navigator.acceptLanguages
Product: WebKit Reporter: Jungshik Shin <jshin>
Component: New BugsAssignee: 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   

Description Jungshik Shin 2009-07-22 12:49:38 PDT
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
Comment 1 Jungshik Shin 2009-07-22 12:52:56 PDT
sorry for bug spams.
Comment 2 Alexey Proskuryakov 2009-07-22 13:43:24 PDT
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.
Comment 3 Aaron Boodman 2009-07-22 14:01:42 PDT
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.
Comment 4 Dylan McCall 2023-09-29 12:51:23 PDT
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.
Comment 5 Alexey Proskuryakov 2023-09-29 13:22:21 PDT
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.