- From: Andrew Cunningham <andj.cunningham@gmail.com>
- Date: Thu, 7 Sep 2017 12:43:33 +1000
- To: "Michael A. Peters" <mpeters@domblogger.net>
- Cc: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Message-ID: <CAOUP6K=rf_43pj-tnBj2B=f-kFCEzLHmcZsPwMYM5s2UjkcPPA@mail.gmail.com>
On Thursday, 7 September 2017, Michael A. Peters <mpeters@domblogger.net> wrote: > On 09/06/2017 01:38 PM, Andrew Cunningham wrote: > >> >> >> On Wednesday, 6 September 2017, Michael A. Peters >> <mpeters@domblogger.net <mailto:mpeters@domblogger.net>> wrote: >> >> Don't need to map to a different glyph based on locale. Plenty of >> localization scripts exist for software. >> >> >> >> Selecting a glyph in a font would be based on language not on locale. >> > > In fact some web applications do look at the locale setting part of the > language for things like time/date format etc. even when the language sent > is the same. > > Of course they would look at locale setting of browser for time/date formats since they are part of the locale definition. But available browser locales may not have anything to do with what language the user is using or prefers to see content in. Likewise there may not be any defined locale to match the language of the content. Available locales will differ from user agent to user agent. And not all aspects of a particular locale may be available on a specific user agent. Locale are useful. Usually server side locale sout ions are more complete implementations. But depending on language of content, should be used with an understanding of implementation limitations. Andrew > The same could easily be done for locale specific interface glyphs. > > > -- Andrew Cunningham andj.cunningham@gmail.com
Received on Thursday, 7 September 2017 02:43:56 UTC