Human readable error message without language info

[himorin]

5.10. WebTransportCloseInfo Dictionary
https://www.w3.org/TR/webtransport/#web-transport-close-info

dictionary WebTransportCloseInfo {
unsigned long closeCode = 0;
DOMString reason = "";
};

9. WebTransportError Interface
   https://www.w3.org/TR/webtransport/#web-transport-error-interface

dictionary WebTransportErrorInit {
[Clamp] octet streamErrorCode;
DOMString message;
};

Is there a way to indicate the language and direction of the ‘informative human-readable message’?

How is the language chosen? Does it adapt to the user whose screen is being captured?

Related information: similar issue for other specification (w3c/mediacapture-main#673), Strings on the Web WG Note, TAG design review

[LPardue]

The WebTransport mechanism relies on QUIC CONNECTION_CLOSE, which has the following to say about the reason phrase in https://www.rfc-editor.org/rfc/rfc9000.html#section-19.19-6.8.1:

Reason Phrase: Additional diagnostic information for the closure. This can be zero length if the sender chooses not to give details beyond the Error Code value. This SHOULD be a UTF-8 encoded string [RFC3629], though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text.

Barry Leiba provided some additional insight on this in quicwg/base-drafts#4647 (comment).

Based on QUIC's design and rationale, the Reason Phrase is not intended to be consumed by end users. UTF-8 allows for multiple languages as implementations see fit but QUIC does not provide a language negotiation feature.

[aphillips]

The I18N WG discussed this in our teleconference of 2022-09-01. We agree that your API doc is describing an existing RFC-defined protocol, which does not include language/direction metadata. As such, it is not possible for you to manufacture this metadata for consumers and there is no point in collecting metadata for serialization. We discussed that it might be helpful to indicate that no such information is available in your spec (particularly to indicate that first-strong heuristics should be used for direction when displaying the values) and created an action item to provide guidance for this specific type of situation going forwards. So we are satisfied by your response.

---

I don't agree that the Reason Phrase is "not intended to be consumed by end users": it is intended to be consumed by humans rather than machines. Error messages of this type are frequently not provided with additional metadata such as language/direction because they are mostly seen by operators (in logs and such). The lack of language negotiation mechanisms and such for the protocol is something that the QUIC folks might (or might not) consider a gap in their internationalization. As it is, I tend to agree with the original comment in quicwg/base-drafts#4647 (and indeed this is what our String-Meta doc and related efforts are all about). Barry Leiba's argument is basically that the natural language used by a system or set of systems is provided solely by private external agreement. While there are places in the Web/Internet where language and direction metadata is overkill (and these specific fields probably qualify), this does represent a gap in usability. Reading our doc, explainers, etc. may help your group (and others) appreciate the problem and why UTF-8 and Unicode are not sufficient when working with natural language strings.

[wilaw]

We will add language to sect 5.6.2.6 to indicate that no language or direction metadata is available with reasonBytes and that first-strong heuristics should be used for direction when displaying the values.

[jan-ivar]

dictionary WebTransportErrorInit {
... Is there a way to indicate the language and direction of the ‘informative human-readable message’?

As of #460 this spec follows upcoming guidance for error handling, which removes any mention of human readable message in this spec.