- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Thu, 7 Sep 2017 00:23:58 -0700
- To: w3c-wai-ig@w3.org
Bottom line is the client sends the language as a header to the server so worst case scenario the server can choose the right unicode glyph to send based upon the header sent by client. Best case scenario, browsers can substitute the glyph when they parse the page based upon the locale set in the operating system. Either natively or via a user installed extension. Kind of like how privacy badger changes the html to foil detected trackers. Those client side options aren't really available when the CC button is an image, the server must support other locales or the user is stuck with the default. On 09/06/2017 07:35 PM, Andrew Cunningham wrote: > Language tag and locale tag are two different things for different > purposes. Both use BCP47. Although language tags don't need the -u- > extension. In your example the country code is irrelevan in terms of > glyph selection in a font. The only significant part of tag is the 'en' > subtag which would match either default OT script or a specific OT > language system. And an OT language system is not the se as either a > locale or language tag. > > Andrew > > On Thursday, 7 September 2017, Michael A. Peters <mpeters@domblogger.net > <mailto:mpeters@domblogger.net>> wrote: > > Browser language settings include locale, e.g. en-US vs en-GB etc. > > 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. > > Although if a cvNN feature was available in a font you could > modify a > localisation script to change the css to target a specific glyph. > > But considering potential font fallback issues ... using a > textual label > can be problematic. > > Andrew > > > > > -- > Andrew Cunningham > andj.cunningham@gmail.com <mailto:andj.cunningham@gmail.com> > > > > > > -- > Andrew Cunningham > andj.cunningham@gmail.com <mailto:andj.cunningham@gmail.com> >
Received on Thursday, 7 September 2017 07:24:24 UTC