Re: [presentation-api] Possibility for a character to be interpreted differently depending on locale

>> My understanding is that, is such a mechanism is in place, it would
 also address the language-specific font selection issue that is at 
stake here: if the controlling side can tell the receiving side to 
override its language settings to Japanese before it downloads the 
content, the receiving side could also use that info to use a Japanese
 font as default font in the absence of other information.

> i'm not sure that really follows. Suppose the language asked for is 
not available.  Usually the server would fall back to another 
language...

Right, but I don't think that matters for our use case. See the 
Internet café example below.

> Also, the accept-language data is set in the browser and is unlikely
 to be altered much of the time. In fact, in some browsers it's not 
possible to easily change it.

What is specific to the Presentation API is the existence of a control
 channel that the controlling user agent uses to send commands such as
 "load that URL" to the receiving user agent. How this works in 
practice is up to implementations for the time being, but it is easy 
to envision that this control channel could also be used to pass 
language settings to the receiving user agent so that it temporarily 
alters its language settings.


>  If you speak both Chinese and Japanese, say, and wanted to receive 
information in both languages from one time to the next, it would be a
 pain, if possible at all, to change the accept-language header 
depending on which language you wanted to read.  And if your 
accept-language setting was set to en but you still wanted to see the 
content properly rendered (as might be the case for someone like 
myself), you'd be back to the situation of pot-luck as to whether 
ideographic characters were married to the right font. This would also
 be the case for a Japanese/Chinese person looking up data in one of 
those languages in an internet cafe in the UK.

Who is "you" in this description? With the Presentation API, we have 
two potential "you": one "you" is the controlling user agent, and the 
other "you" is the receiving user agent. In most envisioned scenarios,
 the user would be the same, so we would prefer both underlying user 
agents to behave similarly.

If a Japanese person goes to an Internet café in the UK with her 
Japanese smartphone (the controlling user agent) and wants to make use
 of a second screen available there to render a given URL, she would 
probably want the second screen (the receiving user agent) to render 
the content at that URL as it would be rendered on her smartphone.

If the content is served in Japanese through HTTP content negotiation 
on her smartphone, then she would want to see the Japanese version on 
the second screen as well, if possible. And so, she would want her 
controlling user agent to tell the receiving user agent to temporarily
 switch to the same language settings as her smartphone before it 
downloads and renders the page.

If the content is served in English even when Japanese is requested, 
then so be it, she would see the content in English on the second 
screen as she would see the content in English on her smartphone, 
perhaps still using a Japanese variant of an English font (if such a 
thing exists) in both cases.

What we would prefer to avoid is a situation where she sees English on
 the second screen while she would see Japanese on her smartphone. 
Said differently, the second screen is to be an extension of her 
smartphone, not a completely separated device.


> Thirdly, what about a situation where some of the data is in 
Japanese, and some in Chinese. Accept-language is too blunt an 
instrument to handle that at all.

That's understood, I am not suggesting we can solve this particular 
point with an `accept-language` hammer. I hope the above example 
explains the background better.


-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/218#issuecomment-157182419
 using your GitHub account

Received on Monday, 16 November 2015 21:53:55 UTC