Repository navigation
list of displays: should it address display name, language, etc.? #315
Description
The I18N working group is doing some housekeeping and found that we didn't forward the below issue. Apologies for being late with this. Note that this may already be addressed by other threads about language.
http://w3c.github.io/presentation-api/
Section: The list of available presentation displays
This section contains the directive that:
The user agent MUST keep a list of available presentation displays. This current list of presentation displays may be used for starting new presentations, and is populated based on an implementation specific discovery mechanism. It is set to the most recent result of the algorithm to monitor the list of available presentation displays.
This list appears to be identified using URLs for each presentation display. The specification is silent about such issues as display name, sorting order, etc. These issues may affect actual implementation, even though this API doesn't really address the issue. Should it?
Activity
aphillips commentedon Jun 12, 2016
(could you please add the label "i18n" to this issue?)
tidoust commentedon Jun 14, 2016
I believe that the specification is silent on purpose here, to let implementers adjust their chrome and user experience as they see fit. For instance, a controlling user agent could choose to list displays that the user previously interacted with first, or sort displays it finds by proximity, or filter out displays that it deems not trustworthy, etc. In other words, the expectation is not that two controlling user agents will display the same list of available displays, and that they will appear in the same order.
The amount of information that the controlling user agent has on the available displays also depends on the discovery mechanism used under the hoods, which is out of scope of this specification. The user agent may be able to learn about all sorts of capabilities that the display supports, including locale support. Or it may not know much on top of the display name.
The spec could perhaps include some guidance about possible localization issues. I'm not clear how the display name could affect the actual implementation though. Do you have examples of issues that could arise, @aphillips ? For instance, is the problem that the user agent may not be able to render the name if the display name uses characters that are not supported by the user agent?
Side note: the list of displays is not identified using URLs. Each presentation display is associated with a list of URLs that it is compatible with, but it is not an identifier for the display. How the display gets identified is up to the implementation. It will probably be based on its IP address (possibly its MAC address on the LAN), or on some identifier exposed by the display itself.
aphillips commentedon Jun 14, 2016
@tidoust There are a number of issues that could arise, but these would depend on implementation details. As long as the spec doesn't make normative statements about the presentation of the list, though, I'm not sure you need to enumerate what all of the potential problems are. Which is why the issue basically asks "should there be something here?". I'm not sure that there should be.
The main issues for presentation of individual display names would be language and direction metadata. These ought to be provided so that font selection/fallback works appropriately (language) and so that mixed direction display names are correctly formatted (direction). However, if I recall correctly, we've dealt with those in separate issues. Lack of local fonts for displaying characters is a problem that can arise but not something your spec can really address either: it is just a general problem for user agents.
Of the other issues that occur to me, sorting of the list is probably the main I18N issue that implementers might trip over. Unicode code point order is not a particularly user-friendly sorting, but proper collation involve the user's locale expectations. But your spec is silent about how the list is presented. I'd suggest leaving well enough alone and would suggest you close the issue.
tidoust commentedon Jun 14, 2016
Thanks for the feedback @aphillips.
We've dealt with language issues for messages exchanged between the controlling side and the receiving side over the communication channel (the spec now includes guidance for developers and a related example), as well as for passing the locale from the controlling side to the receiving side (now a SHOULD in the spec), but not really for the list of available displays.
I don't see how the spec could mandate anything on the topic, but it could perhaps point out that receiving user agents are encouraged to advertise the language and direction metadata along with their display name. I do not know if that it is actually doable with usual advertising protocols on the LAN though.
tomoyukilabs commentedon Jun 20, 2016
@tidoust
As far as I investigated, it might depend on advertising protocols. In SSDP, parameters such as
<friendlyName>, etc. indicated in UPnP Device Description can be localized byAccept-LanguageandContent-LanguageHTTP headers (see Section 2.3 in UPnP Device Architecture). However, I am not sure whether there is any display applying such localization or not. On the other hand, mDNS does not seem to provide any record to indicate the language of display's name.markafoltz commentedon Aug 18, 2016
For background, there are a couple of reasonable ways a friendly display name can be passed through mDNS:
What I propose is implementation guidance along the lines of @tidoust:
[1] https://tools.ietf.org/html/rfc6763#section-4.1
[2] https://tools.ietf.org/html/rfc6763#section-6