- From: David Singer <singer@mac.com>
- Date: Tue, 17 Oct 2017 12:23:11 +0100
- To: "Phillips, Addison" <addison@lab126.com>
- Cc: Mike O'Neill <michael.oneill@baycloud.com>, "public-tracking@w3.org" <public-tracking@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Can we put the discussion into the issue itself, so it’s trackable, please? > On Oct 15, 2017, at 19:51 , Phillips, Addison <addison@lab126.com> wrote: > > Hi Mike, > > The Accept-Language header is one mechanism for negotiating language between the user-agent and the producer of the data. It’s the only mechanism built in to HTTP, but there are limitations to using it. Some systems negotiate language in other ways (such as cookies, URL, etc.). It’s worth mentioning Accept-Language as one mechanism for returning tracking-related messages to the user. If you mention Accept-Language in a note, it would probably be a note that says something like the following and isn’t particularly normative about how it works: > > Ø Natural language values such as ‘name’ and ‘explanation’ should be localized into the language that the user expects. Language negotiation between the server and user might use the value of the user-agent’s Accept-Language header or some other appropriate means of determining which language this is. > > Note that some of our comments have to do with user-agent local values and the user-agent may have more information than a Web request regarding the localization that the user expects. A script running in the user-agent has access to the user’s runtime environment and browser localization. For example, many browsers now implement ES-402 and that can be used to determine a locale [1] > > The other point in my comments is that the return value doesn’t indicate or provide a means to indicate the language or base text direction of the natural language text values. While it might be nice to provide more than one language in the response (so that the user/user-agent can choose which one to display or use), there are limitations to how many a given server can or even should return. In some cases it may depend on the configuration of the server as to which language(s) are used. However, rendering of natural language content is affected by the language and text direction. This meta data is important, even if the server can only return a single language. We have a document under development that explains more about this problem: https://w3c.github.io/string-meta > > Hope that helps, > > Addison > > [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#Locale_negotiation > > Addison Phillips > Principal SDE, I18N Architect (Amazon) > Chair (W3C I18N WG) > > Internationalization is not a feature. > It is an architecture. > > > > From: Mike O'Neill [mailto:michael.oneill@baycloud.com] > Sent: Saturday, October 14, 2017 12:02 PM > To: Phillips, Addison <addison@lab126.com>; public-tracking@w3.org > Cc: public-i18n-core@w3.org > Subject: RE: I18N review of tracking-DNT CR update [I18N-ACTION-662] > > Hi Addison, > > Would some mention of the accept-language header i.e. in the origin making the API call (using the explanation property), or in the privacy policy resource? > > Is there a recommended way for script to detect the user’s locale? > > Thanks for your attention to this! > > Mike > > From: Phillips, Addison [mailto:addison@lab126.com] > Sent: 14 October 2017 19:43 > To: public-tracking@w3.org > Cc: public-i18n-core@w3.org > Subject: I18N review of tracking-DNT CR update [I18N-ACTION-662] > > Dear Tracking WG, > > I have been actioned [1] by the Internationalization Working Group to report back the status of our horizontal review of your document [2] which you recently requested. > > In reviewing the document, I found the following three issues. These have not yet been reviewed by the I18N WG, so their current status is that they are personal comments pending review. I’m providing links to our issues so that you have advance notification. If the WG accepts these issues, we will file them as issues in your Github repo, following our normal process. That way discussion of these issues can be in your space. > > https://github.com/w3c/i18n-activity/issues/508 > https://github.com/w3c/i18n-activity/issues/509 > https://github.com/w3c/i18n-activity/issues/510 > > We look forward to any discussion required. > > Regards (for I18N), > > Addison > > Addison Phillips > Principal SDE, I18N Architect (Amazon) > Chair (W3C I18N WG) > > Internationalization is not a feature. > It is an architecture. > ---- > > [1] https://www.w3.org/International/track/actions/662 > [2] https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html Dave Singer singer@mac.com
Received on Tuesday, 17 October 2017 11:24:42 UTC