- From: Andrew Cunningham <lang.support@gmail.com>
- Date: Wed, 10 May 2023 19:23:46 +1000
- To: Addison Phillips <addisoni18n@gmail.com>
- Cc: Internationalization Working Group <public-i18n-core@w3.org>
Received on Wednesday, 10 May 2023 09:24:01 UTC
Addison, It is something I have been considering since work started on ICU4X. I tend to support lesser used and minority languages as well as mainstream languages. Implementing a locale in CLDR has overheads and barriers so it's much more useful to leverage off libc locales (which are more limited) combined with rule based classes in ICU4C/ICU4J I understand the concerns around fingerprinting but reality is for minority language groups if fingerprinting is a design goal then these groups will be technically marginalised. If locales can not be added to browsers, then either: 1. Two architectures and approaches are needed: web browser based solutions for some locales and server based solutions for all others, 2. All locale based operations handled at server not browser, or 3. A rapid program to develop and deploy many more locales. Web browsers would conceivably need to add hundreds (or thousands) of additional locales (and variations) over time. Andrew On Wed, 10 May 2023, 18:21 Addison Phillips, <addisoni18n@gmail.com> wrote: > https://github.com/tc39/ecma402/pull/780 > > > > The above PR would forbid browsers from installing a locale (in a bid to > prevent fingerprinting). In that regard it can be like the thread we’ve had > about fonts. Should we weigh in? > > > > Addison Phillips > > Chair (W3C Internationalization WG) > > > > Internationalization is not a feature. > > It is an architecture. > > >
Received on Wednesday, 10 May 2023 09:24:01 UTC