Re: [css-variables][i18n] :lang() Example

Liam R E Quin <>:
> On Tue, 2014-06-17 at 13:44 +0200, Christoph Päper wrote:
>> I believe the spec of the Custom Properties for Cascading Variables
>> module would benefit from an example that showed how to use variables
>> for internationalization, e.g.
>>  :root:lang(en) {--external-link: "external link";}
>>  :root:lang(de) {--external-link: "externer Link";}
>>  a[href^="http"]::after {content: " (" var(--external-link) ")"}
> I think the Internationalization best practice currently suggests not
> putting all languages in the same file;

I didn’t say they should; you could make one CSS file per language as well. The point is to have translatable strings localized [pun intended] in a single place, so the translator(s) can easily edit them without having to mess with non-textual styles, like François Remy said.

> furthermore this approach won't
> work if e.g. you have Japanese or Chinese with "ruby" annotations, or if
> for some other reason you need markup or formatting in the content.

Sure, but that’s a general comment on the ‘content’ property. You can use it right, though, and if you find yourself needing markup in such strings, chances are high you’re misusing it.

>> Features and values from GCPM etc. are more powerful if used this way.

I was thinking of translations of ‘chapter’, ‘page’ etc. CSS could of course also – in a new module “CSS Internationalization” – provide and curate a list of keywords for such standard phrases translated into many languages, cf. (La)TeX’s ‘babel’ and ‘polyglossia’ packages.

> The two-argument element() isn't widely
> implemented, so you end up with extra copies of text in your document,
> but this is likely to be better than having document content in CSS,
> especially for accessibility.

Reduplication can hinder accessibility just as much as omission. Nevertheless, as I said, ’content’ can be used in accessible ways that still need translations.

Received on Wednesday, 18 June 2014 07:46:08 UTC