Closed aphillips closed 3 years ago
Are there additional questions? If not we may close this issue.
Closing this issue since we have heard no objects.
I was actioned with reopening this issue by I18N WG. We remain concerned that there are duplicate lists and that, by forking from HTML, you are importing a myriad of internationalization woes from that spec. For example, there are several date and time related fields, but no mention of different non-Gregorian calendar systems. There is a country code type but not a reference to country/region code standards such as ISO3166 or BCP47's registry. Etc.
Is it possible to separate this material and use it by reference? Or should we comment in detail on these keywords because you intend them to be distinct from HTML?
Thank you for this feedback.
The Personalization Task Force are sensitive to these concerns, which is why we strongly support recent efforts/discussions around the creation of a W3C Registry for important spec fragments such as this.
One of our concerns however is the need for a rigid 'taxonomy' which we can explicitly control, which unfortunately discounts the current list referenced in the WHAT WG HTML5 Specification. (We also note that the same list is mirrored in WCAG 2.1 - Section 7 for exactly the same reason)
Due to the fact that many of our Accessibility specifications also become part of legally legislated requirements (etc.), and the fact that this emergent technology solution will likely be adopted as part of WCAG 2.x/WCAG 3.x this is a risk we cannot afford to take: if WHAT WG makes changes to their specification, it could invalidate or frustrate other requirements we must account for.
We also appreciate the direct feedback with regard to specifying 'which' ISO language codes can and should be used [*], as well as alternative calendaring systems, which the group will discuss and respond back with a proposed editorial change.
[ NOTE: WCAG 2.1's list is also remise w.r.t. specifying which* language code should be used: https://www.w3.org/TR/WCAG21/#input-purposes - will i18n file an issue there, or would your group prefer we do so?]
@johnfoliot Thanks for the update.
WRT the language
item, I am opening an additional issue now.
I18n appears to accept our response. Closing as resolved.
(From your I18N self-review #133)
@becka11y suggests: