[svgwg] Issue: [i18n] Language fragment identifier for conditional processing marked as Needs WG input

AmeliaBR has just labeled an issue for https://github.com/w3c/svgwg as
 "Needs WG input":

== [i18n] Language fragment identifier for conditional processing ==
SVG already supports [conditional 
processing](https://svgwg.org/svg2-draft/struct.html#ConditionalProcessing)
 based upon the environment of the renderer using `<switch>` and 
attributes `requiredExtensions` or `systemLanguage` in child elements.
 As far as I can tell, there’s no way defined for users to explicitly 
request a certain language when they’re embedding SVG images into 
their content. A straightforward way to achieve this would be fragment
 identifiers in URLs, which other file formats already use (e.g. 
`bar.pdf#page=5`):

    <img src="foo.svg#lang=en" alt="Foo in English">
    
    :root:lang(en) {background: url(foo.svg#lang=en);}

It’s obvious that BCP47 codes would be used as values. I’m not sure 
multiple (comma-separated?) values needed to be supported. I don’t 
care whether the fragment ID key actually read `lang` (as in XML and 
HTML), `language`, `preferredLanguage` or something else. I neither 
find it important whether this was defined in the core SVG spec itself
 or in an auxiliary standard. The use case for explicitly activated 
extensions seems much less important to me, but could also be defined 
for completeness.

Multilingual sites like Wikipedia (drawing much of its image data from
 central Wikicommons) could then automatically add the identifier 
(usually already found in the third-level domain name) or let their 
authors set it explicitly:

    [[File:Foo.svg#lang=en|Foo in English]]
    [[File:Foo.svg|language=English|Foo in English]]

Today, there are lots of monolingual image resources like `Foo_en.svg`
 instead, which can pose a maintainance concern.

See https://github.com/w3c/svgwg/issues/201

Received on Tuesday, 12 July 2016 17:03:15 UTC