Editorial: Make "structurally valid language tag" an auto-linked term #1008
Conversation
…nical" to "structurally valid" Canonicalization is already performed by MakeLocaleRecord, and not needed before it.
| 1. Let _tag_ be ? ToString(_tag_). | ||
| 1. Set _options_ to ? CoerceOptionsToObject(_options_). | ||
| 1. If IsStructurallyValidLanguageTag(_tag_) is *false*, throw a *RangeError* exception. | ||
| 1. Set _tag_ to CanonicalizeUnicodeLocaleId(_tag_). |
There was a problem hiding this comment.
Removing canonicalisation is still a normative change: #804 (review)
There was a problem hiding this comment.
All right, that's twice now... this is clearly too subtle, so I've added an explanatory note.
…m "canonical" to "structurally valid"
…nicalization The relevant algorithms are buried rather deep in that section.
gibson042
changed the title
gibson042
added
editorial
|
@anba could you take a quick look again? Thanks! |
aphillips
left a comment
aphillips
left a comment
There was a problem hiding this comment.
See comment. There are many places where we've managed the language tag validation jargon into "well-formed" vs. "valid". I know there is additional complexity in the locale identifier space, but we should be cautious not to make understanding more difficult.
| <h1> | ||
| UpdateLanguageId ( | ||
| _tag_: a Unicode canonicalized locale identifier, | ||
| _tag_: a structurally valid language tag, |
There was a problem hiding this comment.
"structurally valid language tag" already has the name "well-formed" in BCP47 (and elsewhere). The term "valid" also has a meaning in that space: it means that the subtags have been validated. Inventing a term here that uses the word "valid" but which means apparently "well-formed" would be bad news. I would strongly urge using "structurally well-formed language tag" if not just "well-formed language tag".
4 participants
No description provided.