Re: [whatwg] Proposal: Locale Preferences API
On Tue, 17 Dec 2013, Mark Callow wrote: On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: 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). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. It's a good question. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. This is almost certainly the cause. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. I don't think this is visible to the page currently, except indirectly via navigator.language, so if your browser is configured to only report English, that's all the page should see. The feature requested in this thread did end up being added to the spec: http://whatwg.org/html#language-preferences It's basically just an array version of navigator.language, and the spec suggests using the same list as for Accept-Language, so it doesn't really provide anything new, it's just more convenient. It's true that Accept-Language doesn't seem to have been widely used. The feature was primarily added due to requests from implementors. I don't know what we can do to cause authors to rely on this API and its siblings rather than on IP geolocation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Locale Preferences API
On Thu, 12 Dec 2013, Jungshik Shin (신정식, 申政湜) wrote: 2013/11/27 Boris Zbarsky bzbar...@mit.edu On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. Well, the vast majority of users would never touch A-L list. So, the top entry in the A-L list would remain the default value, which is usually the UI language. So, I don't know how much your change helps privacy if revealing the UI language is indeed a valid privacy concern. On Fri, 13 Dec 2013, Boris Zbarsky wrote: The point is, the Accept-Languages header already reveals whatever it reveals, so there is no additional privacy leak from navigator.language if you just mirror what the header. And for people who _do_ change the A-L list, they get it picked up in both places automatically. It does seem reasonable that the three APIs (the header and the two IDL attributes, one giving one value and the other a list) would expose the same information, or at least subsets thereof (for the single value one). Jungshik, is there any particular reason for _not_ doing this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Locale Preferences API
I sent this quite some time ago but have never seen it on the mailing list so I am sending it again. On 2013/10/31 14:41, Mark Callow wrote: On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: 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). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. Locale != language so if they are doing the latter it is just wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Proposal: Locale Preferences API
On 12/12/13 7:56 PM, Jungshik Shin (신정식, 申政湜) wrote: Well, the vast majority of users would never touch A-L list. So, the top entry in the A-L list would remain the default value, which is usually the UI language. So, I don't know how much your change helps privacy if revealing the UI language is indeed a valid privacy concern. The point is, the Accept-Languages header already reveals whatever it reveals, so there is no additional privacy leak from navigator.language if you just mirror what the header. And for people who _do_ change the A-L list, they get it picked up in both places automatically. -Boris
Re: [whatwg] Proposal: Locale Preferences API
2013/11/27 Jukka K. Korpela jkorp...@cs.tut.fi 2013-11-28 0:20, Boris Zbarsky wrote: On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. More importantly, I would say, the browser’s UI language should normally be completely irrelevant to page design and implementation. I might be using an English-language browser because there is no better option (localizations are lousy). This does not mean that when viewing a page in, say, German, I would want the page to talk to me in English, to use English-language month names in date controls and info, etc. Sure. I don't disagree with you. But, I have no idea what you wrote above has anything to do with what I wrote, i.e navigator.language (singular) containing the UI language and navigator.languages (plural) matching the Accept-Language HTTP header. Jungshik Yucca
Re: [whatwg] Proposal: Locale Preferences API
2013/11/27 Boris Zbarsky bzbar...@mit.edu On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. Well, the vast majority of users would never touch A-L list. So, the top entry in the A-L list would remain the default value, which is usually the UI language. So, I don't know how much your change helps privacy if revealing the UI language is indeed a valid privacy concern. Jungshik -Boris
Re: [whatwg] Proposal: Locale Preferences API
The proposal looks good except for one reservation I have about. A few years ago, we proposed a similar API to webkit-dev, but it's 'killed' there and we didn't bring it up in whatwg (Chromium ended up adding an extension API for that for Chrome extensions). My reservation is : it's not a good idea to conflate the browser's UI language and the ordered list of preferred content languages (Accept-Language). Specifically, I think it's better to leave alone 'navigator.language' when the preferred list of languages is changed. *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.* That is, I suggest that 'navigator.language' always be the UI language of a web browser. When the 'preferred lang list' changes, it should NOT affect 'navigator.language' (singular) but ONLY updates 'navigator.languages' (plural). If 'language vs languages' is likely to cause confusion/errors, we might as well choose to use 'preferredLanguages' or 'preferredContentLanguages' for the latter. Jungshik 2013/10/16 Erik Arvidsson a...@chromium.org This looks very useful and the proposal looks solid. On Mon, Oct 14, 2013 at 6:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Oct 2013, Marcos Caceres wrote: Ping? Mozilla would like to know if anyone else is interested or specially if people are NOT interested. We would like to implement this and expose it on the platform. See: https://bugzilla.mozilla.org/show_bug.cgi?id=780953 I was just looking at this, actually. I filed the following bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517 Seems like a reasonable feature to me, FWIW. See also: Notification of change to navigator.language (locale change) https://www.w3.org/bugzilla_public/show_bug.cgi?id=21289 API to expose locale-specific settings https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679 API to expose actual language of a node, to aid scripts doing localisation and CJK editors during copypaste and dragdrop https://www.w3.org/Bugs/Public/show_bug.cgi?id=23512 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- erik
Re: [whatwg] Proposal: Locale Preferences API
On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. -Boris
Re: [whatwg] Proposal: Locale Preferences API
2013-11-28 0:20, Boris Zbarsky wrote: On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. More importantly, I would say, the browser’s UI language should normally be completely irrelevant to page design and implementation. I might be using an English-language browser because there is no better option (localizations are lousy). This does not mean that when viewing a page in, say, German, I would want the page to talk to me in English, to use English-language month names in date controls and info, etc. Yucca
Re: [whatwg] Proposal: Locale Preferences API
On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: 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). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. Locale != language so if they are doing the latter it is just wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Proposal: Locale Preferences API
This looks very useful and the proposal looks solid. On Mon, Oct 14, 2013 at 6:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Oct 2013, Marcos Caceres wrote: Ping? Mozilla would like to know if anyone else is interested or specially if people are NOT interested. We would like to implement this and expose it on the platform. See: https://bugzilla.mozilla.org/show_bug.cgi?id=780953 I was just looking at this, actually. I filed the following bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517 Seems like a reasonable feature to me, FWIW. See also: Notification of change to navigator.language (locale change) https://www.w3.org/bugzilla_public/show_bug.cgi?id=21289 API to expose locale-specific settings https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679 API to expose actual language of a node, to aid scripts doing localisation and CJK editors during copypaste and dragdrop https://www.w3.org/Bugs/Public/show_bug.cgi?id=23512 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- erik
Re: [whatwg] Proposal: Locale Preferences API
Ping?
Mozilla would like to know if anyone else is interested or specially if people
are NOT interested. We would like to implement this and expose it on the
platform.
See:
https://bugzilla.mozilla.org/show_bug.cgi?id=780953
On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote:
tl;dr: Mozilla would like your feedback on the following proposal to extend
HTML to expose the user's locale preferences - which would allow for more
dynamic localization of content. To HTML, we would like to add a
`navigator.languages` attribute and a `languageschange` event (and
corresponding EventHandler on the Navigator interface).
The following markdown is also viewable online (feedback in the form of Pull
Requests is welcome!):
https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md
# Proposal: Locale Preferences 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.
## Acquiring the end-user's locale preferences
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.
## Extensions to Navigator interface
```WebIDL
partial interface Navigator : EventTarget {
readonly attribute DOMString[] languages;
attribute EventHandler onlanguageschange;
}
```
Note: We've received feedback that TC39 is not in favor of API's using frozen
/read-only arrays. Alternatives to the above attribute are:
1. `sequenceDOMString getLanguages()` method - thought this has been
internally criticized as being javaish.
2. Willfully violate WebIDL's ban on using sequences on attributes, and make
`languages` just return `sequenceDOMString`.
## 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
Re: [whatwg] Proposal: Locale Preferences API
On Mon, 14 Oct 2013, Marcos Caceres wrote: Ping? Mozilla would like to know if anyone else is interested or specially if people are NOT interested. We would like to implement this and expose it on the platform. See: https://bugzilla.mozilla.org/show_bug.cgi?id=780953 I was just looking at this, actually. I filed the following bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517 Seems like a reasonable feature to me, FWIW. See also: Notification of change to navigator.language (locale change) https://www.w3.org/bugzilla_public/show_bug.cgi?id=21289 API to expose locale-specific settings https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679 API to expose actual language of a node, to aid scripts doing localisation and CJK editors during copypaste and dragdrop https://www.w3.org/Bugs/Public/show_bug.cgi?id=23512 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal: Locale Preferences API
tl;dr: Mozilla would like your feedback on the following proposal to extend
HTML to expose the user's locale preferences - which would allow for more
dynamic localization of content. To HTML, we would like to add a
`navigator.languages` attribute and a `languageschange` event (and
corresponding EventHandler on the Navigator interface).
The following markdown is also viewable online (feedback in the form of Pull
Requests is welcome!):
https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md
# Proposal: Locale Preferences 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.
## Acquiring the end-user's locale preferences
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.
## Extensions to Navigator interface
```WebIDL
partial interface Navigator : EventTarget {
readonly attribute DOMString[] languages;
attribute EventHandler onlanguageschange;
}
```
Note: We've received feedback that TC39 is not in favor of API's using frozen
/read-only arrays. Alternatives to the above attribute are:
1. `sequenceDOMString getLanguages()` method - thought this has been
internally criticized as being javaish.
2. Willfully violate WebIDL's ban on using sequences on attributes, and make
`languages` just return `sequenceDOMString`.
## 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.
## Privacy considerations
As with
