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

Liam R E Quin <liam@w3.org>:
> 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