- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Nov 2016 11:02:31 +0000
- To: public-secondscreen@w3.org
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