Re: Unicode character for CC symbol?

> 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.

Of course they are available. Generally user interface localisation is
achieved by dereferencing values from a pre-defined list (e.g. a numerical
value understood to mean the "File" menu) into the specific string or
resource to be presented, using some kind of lookup against a table that
varies based on localisation. Hence menu items will get a different string
of unicode points for that menu for English ("File") compared to, say,
French ("Fichier"). It is not usually done at the level of mapping
individual code points into glyphs.

I don't know how many systems localise user interface icons like this - I
imagine that icons are generally designed to be universal. But I would put
the selection of alternate versions in this layer rather than having a
single Unicode point for which glyph selection would require localisation
awareness.



On 07/09/2017, 08:23, "Michael A. Peters" <mpeters@domblogger.net> wrote:

>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 08:54:29 UTC