[remote-playback] Internationalization considerations

tidoust has just created a new issue for 
https://github.com/w3c/remote-playback:

== Internationalization considerations ==
It is good practice to evaluate the spec against [internationalization
 
techniques](http://www.w3.org/International/techniques/developing-specs)
 before requesting horizontal review from the i18n group. Most of 
these points do not seem to apply to the Remote Playback API though.

It seems useful to take a look at the Presentation API and draw 
parallels. I think the following i18n-related aspects of the 
Presentation API may warrant notes in the Remote Playback API spec:

1. The note at the end of 
[§6.3.2](https://w3c.github.io/presentation-api/#starting-a-presentation)
 about advertising and using "the locale and intended text direction 
of the user friendly name" of remote playback devices.
2. The text at the end of 
[§6.6.1](https://w3c.github.io/presentation-api/#creating-a-receiving-browsing-context)
 that receiving user agents should fetch resources "with an HTTP 
Accept-Language header that reflects the language preferences of the 
controlling user agent". This cannot be normative text in the case of 
the Remote Playback API because remote playback devices are not a 
conformance class, but an informative note could perhaps highlight 
that implementers are encouraged to pass the locale to the remote 
playback device if possible. Remote playback devices may use that 
information to select the audio track(s) that get enabled as well for 
instance. I'm not entirely clear how media playback remoting affects 
the enabled status of media tracks that compose the media stream, but 
that seems to be in scope of issue #41.

Please view or discuss this issue at 
https://github.com/w3c/remote-playback/issues/66 using your GitHub 
account

Received on Wednesday, 9 November 2016 11:02:42 UTC