W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2016

[remote-playback] Internationalization considerations

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Wed, 09 Nov 2016 11:02:31 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-188219880-1478689349-sysbot+gh@w3.org>
tidoust has just created a new issue for 

== Internationalization considerations ==
It is good practice to evaluate the spec against [internationalization
 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 
 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 
 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 
Received on Wednesday, 9 November 2016 11:02:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:01 UTC