27555 2009-07-22 12:49:38 -0700 Expose the Accept-Language list as window.navigator.acceptLanguages 2023-09-29 13:22:21 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All RESOLVED INVALID P2 Enhancement --- 1 jshin webkit-unassigned aa ap dylan erikkay mjs nickbaum xji oldest_to_newest 133853 0 jshin 2009-07-22 12:49:38 -0700 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 133855 1 jshin 2009-07-22 12:52:56 -0700 sorry for bug spams. 133886 2 ap 2009-07-22 13:43:24 -0700 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. 133890 3 aa 2009-07-22 14:01:42 -0700 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. 1981372 4 dylan 2023-09-29 12:51:23 -0700 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. 1981389 5 ap 2023-09-29 13:22:21 -0700 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.