[i18n-activity] Use of BCP47 term "well-formed" without definition (#1466)

aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== Use of BCP47 term "well-formed" without definition ==
(globally, but link is to specific instance)
https://w3c.github.io/wot-thing-description/#thing

> One [Map](https://w3c.github.io/wot-thing-description/#dfn-map) contained in an @context [Array](https://w3c.github.io/wot-thing-description/#dfn-array) SHOULD contain a name-value pair that defines the default language for the Thing Description, where the name is the [Term](https://w3c.github.io/wot-thing-description/#dfn-term) @language and the value is a well-formed language tag as defined by [[BCP47](https://w3c.github.io/wot-thing-description/#bib-bcp47)] (e.g., en, de-AT, gsw-CH, zh-Hans, zh-Hant-HK, sl-nedis).

In the above quoted text (and elsewhere in the document) there is a reference to "well-formed language tags" referencing BCP47. This is the right thing to define and the right level of conformance to BCP47 for this specification. However, "well-formed" is probably mysterious to readers of the specification unless they are familiar with BCP47's use of the term (and the difference from "valid").

I suggest linking to our term "well-formed language tag" in the I18N Glossary (https://w3c.github.io/i18n-glossary/#def_well_formed), at least on the first occurrence. You might also consider using "valid language tag" as the recommendation for the contents of the tag, even if the specification only *requires* well-formed.

---
Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** Then ask the i18n WG to review your comment.

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

4. Replace the text 'url_for_the_issue_raised' below with a link to the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use []() notation - just paste the URL.

5. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. If you added an \*lreq label, add the label 'spec-type-issue' and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

6. Edit this issue to **REMOVE ALL THE INSTRUCTIONS**, ie. the two lines that are '---' and all the text between.

End of instructions.
---



**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1466 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 February 2022 17:05:19 UTC