- From: Christoph Päper via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Jul 2016 13:08:56 +0000
- To: public-svg-issues@w3.org
Crissov has just created a new issue for https://github.com/w3c/svgwg: == [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. Please view or discuss this issue at https://github.com/w3c/svgwg/issues/201 using your GitHub account
Received on Tuesday, 12 July 2016 13:09:15 UTC