[css-counter-styles-3] Support automatically localized counters

[pols12]

Similarly to inline-start keyword which may mean “right” or “left” depending on the language, I think we should support

• digits as an alias of decimal on English pages, arabic-indic on Arabic pages, armenian on Armenian pages…
• lower-alpha as an alias of lower-latin on English pages, hiragana on Japanese pages…
• and maybe bullet as an alias of disc on English pages… (because I suppose the list bullet is also culture-dependant).

With these generic keywords, the user agent should use the counter symbols which are the most appropriate given content language and user preferences.

Affected: https://www.w3.org/TR/css-counter-styles-3/#predefined-counters

That would also extend and simplify the following css-list-3 recommendation:

UAs and host languages should ensure that the list-item counter values by default reflect the underlying numeric value dictated by host language semantics when setting up list item styling in their UA style sheet and presentational hint style mappings.

[tabatkins]

That bit in Lists is about the value, not how the value is represented in text. It just means that host languages with some notion of counters, like HTML's ol, should handle this by using the list-item counter. How that counter value is displayed is an entirely separate issue.

I'm not opposed to a counter-style that varies its display depending on the language of the element, but we'd need to do some work mapping the styles (and choosing a default for a given language, when there are multiple that could apply). Note that directional mapping is already well-defined by Unicode data, so we didn't have to do any extra work there.

Importantly, we also need a concrete use-case - is there a page that this would help you on, where you're currently working around it manually by varying the counter style?

[pols12]

Note that directional mapping is already well-defined by Unicode data, so we didn't have to do any extra work there.

Do you have a link to that map, please? That would help me to implement workaround for this issue.

Importantly, we also need a concrete use-case - is there a page that this would help you on, where you're currently working around it manually by varying the counter style?

I work on page internationalization on Wikimedia Meta-Wiki. For a given source page with a custom stylesheet (“templateStyles”), all translation pages use the same stylesheet. Since inline-start is not well supported by browser, MediaWiki uses CSSJanus to flip left into right. However we currently don’t have any “magical” workaround for list-style-type property.
On that page (partially) translated in Hindi, I would expect upper-alpha markers to be readable by Hindi speakers, that is, even being decimals instead of letters (probably devanagari).

[pols12]

A more generic use case, in MediaWiki core: https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.skinning/i18n-ordered-lists.less

[tabatkins]

Do you have a link to that map, please? That would help me to implement workaround for this issue.

It's based on the unicode bidi algorithm, not a direct script mapping. Individual characters can have a directionality, and you can then obtain a direction for text based on analyzing the characters used. I think all the details are in Unicode TR9.

I work on page internationalization on Wikimedia Meta-Wiki. For a given source page with a custom stylesheet (“templateStyles”), all translation pages use the same stylesheet.

Oh, interesting! All right, sounds reasonable to me at least. ^_^

[tabatkins]

Agenda+ to discuss the possibility of adding a "localized numeric" value, that maps to one of the predefined numeric types based on the element language.

(How should I ping the i18n WG for feedback on this? @r12a ?)

[dbaron]

lower-alpha as an alias of lower-latin on English pages, hiragana on Japanese pages…

This specific suggestion doesn't work because lower-alpha is already a value that means the same thing as lower-latin.

[pols12]

lower-alpha is already a value that means the same thing as lower-latin

This seems me a bit latin-script centered. We could specify that alias as deprecated for a while, but we may indeed want another (temporary or not) name to avoid confusion in documents which mention some items with their respective alpha symbol.

[tabatkins]

Yeah, a lot of the web is latin-centric, unfortunately.

That alias has been around for literally 20 years, tho. It's not getting deprecated.

(That said, using "alpha" to refer to hiragana is incorrect too; it's not an alphabet, it's a syllabary. Having "alpha" refer specifically to the latin alphabet does exclude other alphabetic languages, but at least it's by a huge amount the most commonly used alphabet in the world.)

[r12a]

I just read this thread, and here are some thoughts off the top of my head...

It may indeed be useful to have some generic keywords, but i expect that the mapping from counter-styles to keywords is something the author should be able to do – rather than expecting a registry or depending on the browser implementers to create the mappings.

That would mean creating a syntax that allows authors to map keywords to particular styles, themselves. This would also give authors the ability to specify their own custom styles, which i think will be a major advantage - not only for allowing alternate styling (such as for affixes), but allowing them to use completely new styles (there are certainly more than we have documented so far - in fact i'm about to add a bunch to the ready-made cs doc).

Presumably the styles assigned to a keyword would need to be associated with BCP47 language tags to apply the right style to the content.

That syntax could also allow authors to define their own keywords, rather than requiring them to squeeze their view of the world into some standardised set, which is likely to always be not quite what's needed, or biased towards Latin, or this or that.

It may be helpful, however, to suggest some keywords, such as numeric, alphabetic, additive – these being types of enumeration. We may, though, need to allow a combination of keywords to define a set, such as "alphabetic uppercase" - which would produce the intersection of those two definitions – though that may be going a bit too far.

[pols12]

@r12a You seem to describe actual @counter-style specifications. And I’m not sure to understand how it is related to this issue.

[andjc]

A few thoughts:

• generally counter styles is considered locale data. Also, unless specify a modifier in the locale (such as using the U extension in CLDR) you get the arabic/western digits by default.
• mapping of language to counter style can be non-trivial, there may be a one to many match. For instance Sorani Kurdish can use either of two number systems (depending on whether it is Iraq and Iran) and if the Sorani pages are external to those countries, it is really a developer choice.
• Different developers will want to make different choices. Some developers will want to use native digits for counters, others, if they are using Arabic/western digits in the page for data may choose to use the same number system for counters rather than using different number systems within a page.

If I am working with Hindi data and I require Devanagari digits when programming I have to use the language identifier hi-IN-u-nu-deva when working with the data.

Personally, I would refer the developer specifying the counter (as is currently the practice) or having browsers switch counter systems if the language tag specifies a number system to use.