- From: Addison Phillips via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Sep 2019 02:08:47 +0000
- To: public-i18n-archive@w3.org
@mattgarrish Thanks for the comment. Generally, you want to require valid language tags in content, even if your normative requirement on implementations only extends to well-formed checking. Most specifications are second-order consumers of language metadata--they are using data already provided in the document format (HTML @lang, XML xml:lang, or the document format's language fields/attributes). Generally most specifications are concerned with selecting resources (such as spell check, tokenizers, fonts, etc.) or with matching (selecting which string to show, for example) and don't directly care about the content of the language tag. Invalid-but-well-formed tags just don't match anything and usually fallback schemes provide some behavior that is appropriate. There might be cases where a specification really wants implementation-level checking. In those cases, the result of a tag failing to be valid has to be specified (die? warn? what?). It's also a problem that the registry changes over time, so each implementation is registry-version dependent. The changes over time are small, minor, and mostly "not that interesting", but they *do* exist and real users may encounter interoperability issues if random (out of date) spec implementations start barfing on their (perfectly valid) language tags. So I generally agree with you and the edit I'm working on hopefully spells this out better than the current text. Thoughts? -- GitHub Notification of comment by aphillips Please view or discuss this issue at https://github.com/w3c/bp-i18n-specdev/issues/36#issuecomment-531072094 using your GitHub account
Received on Friday, 13 September 2019 02:08:49 UTC