- From: Addison Phillips via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Sep 2020 14:27:32 +0000
- To: public-i18n-archive@w3.org
Sure it could work and there is nothing implausible about it. In fact, that's actually how locales are set in many applications. Accept-Language is what's called a "language priority list" and one can (and does) do language negotiation to match that to available locales. It's actually an important example. I could reword the text to include language priority lists and language negotiation, but the actual point, though, is to equate language tags with locales (including older stuff like `de_CH.utf8` and `AMERICAN_AMERICA.WE8MSWIN1252`--or even MS Windows LCIDs, which pack the information into bits, e.g. `en-US` == `0x0409`). I do think the text is trying to do a couple of things and maybe getting ahead of itself. Perhaps: > Historically different programming languages or operating environments defined their own locale identifiers. Some examples include POSIX locale identifiers, such as `de_CH.utf8` or `en_US.iso8869_1` or Oracle database's IDs, such as `AMERICAN_AMERICA.AL32UTF8`. These application-specific identifiers, however, were usually based on the same concepts as language tags and could be inferred from language tags. I can then move the A-L stuff under language negotiation. -- GitHub Notification of comment by aphillips Please view or discuss this issue at https://github.com/w3c/ltli/issues/26#issuecomment-701426985 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 September 2020 14:27:35 UTC