Message text not localizable

[r12a]

[from Addison Phillips, endorsed by the i18n WG]

http://w3c.github.io/webrtc-pc/#rtcpeerconnectioniceerrorevent

Error values can contain an attribute:

    readonly attribute USVString      errorText;

This appears to use the text defined here and doesn't allow for localization of the error message. Shouldn't it allow for localization (complete with language and bidi support)

[adamroach]

The field you're referring to comes directly from the STUN/TURN server, and is not generated locally. It is completely analogous to the XMLHttpRequest.statusText field, and the same l18n considerations apply (i.e., it's a server issue, not an API issue).

[aboba]

Since this is a server, not an API issue, I am closing it.

[aphillips]

I don't agree that this is strictly a server issue. The server does generate the message, but it can know what language and base direction the error is generated in; it is incredibly useful to transmit this information with any human readable string--cf. our document String-Meta. Because we didn't notice that this issue was unresolved and because this is not the first or last spec to have unadorned strings for error messages, I don't propose to block webrtc over it. But I would prefer if natural language strings were provided with metadata.

[dontcallmedom]

right now, the protocol used by the server to send the error doesn't support localization metadata, so there is really nothing the API itself could report as far as I can tell.