Last modified: 2014-05-29 20:21:53 UTC
SVG images like the one given above can contain language-specific elements like labels via the <switch>-element. librsvg is able to handle them by simply reading the enviroment variable (See function rsvg_eval_switch_attributes in rsvg-cond.c) This means it is possible to produce language-specific PNGs by invoking like this: env LANG=<locale> rsvg -w<width> file.svg <width>px-<locale>-file.png I tried this out at home, and it worked just fine. Shoudn't it be possible to decide from the language of the page asking for the png which language version is needed and produce them accordingly? Or, to avoid the production of millions of identical images from single-language SVGs, what about a parameter for the Image: tag? General comment: For the moment, this is still a niche idea. It is yet not easy to produce SVGs that utilize these features. Inkscape even supresses the tags in its current version: https://bugs.launchpad.net/bugs/269390 But for the future, it would be feasable to introduce a toolserver gadget like http://toolserver.org/~nikola/svgtranslate.php Maybe I'll do it myself. It depends on whether I get a thumbs-up here.
Compare also bug 15721, which seems to ask about a different language message... Handling the language switch for images in a shared repository would not be as simple, we'd need to add infrastructure to store separate renderings for each language. See also bug 4688 and bug 14320, which propose different methods for templatizing/filtering for language options.
I'm going to make this the master bug for multilingual support of SVGs; it's better to discuss the implementation in one place. --> marking bug 14320 as duplicate of this one --> marking bug 15721 as duplicate of this one --> leaving bug 4688 alone since it's a possible implementation, but it's also more general. Btw the bug in Inkscape was fixed in 2008.
*** Bug 15721 has been marked as a duplicate of this bug. ***
*** Bug 14320 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Handling the language switch for images in a shared repository would not be as > simple, we'd need to add infrastructure to store separate renderings for each > language. > It would be as simple as implementing this switch in parseParamString/makeParamString or am I missing something obvious?
So with Jarry's patch, we now support [[File:some svg|lang=de]] - Does that make this bug fixed? If not, what is the scope of this bug?
*** Bug 55768 has been marked as a duplicate of this bug. ***
It is very sorry to dupe my bug 55768 without even mentioning that it is at least as general as bug 4688 that has been left alone. Bug 55768 should not have been duplicated to bub 16052, but a merge with bug 4688 should have been proposed (supposing that the authors' opinion matters). Layers are the obvious path to go for this kind or features. As both these two bugs say, the possibilities are endless beyond languages. I even show with a one instruction hack that the answer to "Can this be accomplished with a simple XML transformation?" is formally YES. Normally, it's a convention of what the name (label) of a layer must "look like" to force its visibility. To be independent of which editor can produce which tags, the best approach is general, to match any tag with a regex: something like Image:any.svg|tag=<tag_name_>,<regex>,visible|tag=<tag_name_>,<regex>,visible ... For example, <regex>="=ru" means that the tag must contain "=ru" anywhere in the value, "=ru$" at the end ... As a regex is powerful but intimidating, lang=xx could be used as a shortcut for the language convention, translating to the necessary regex. What is Jarry's patch doing?
(In reply to comment #8) > It is very sorry to dupe my bug 55768 without even mentioning that it is at > least as general as bug 4688 that has been left alone. Bug 55768 should not > have been duplicated to bub 16052, but a merge with bug 4688 should have been > proposed (supposing that the authors' opinion matters). > > Layers are the obvious path to go for this kind or features. As both these > two > bugs say, the possibilities are endless beyond languages. I even show with a > one instruction hack that the answer to "Can this be accomplished with a > simple > XML transformation?" is formally YES. > > Normally, it's a convention of what the name (label) of a layer must "look > like" to force its visibility. > To be independent of which editor can produce which tags, the best approach > is > general, to match any tag with a regex: something like > Image:any.svg|tag=<tag_name_>,<regex>,visible|tag=<tag_name_>,<regex>,visible > ... > For example, <regex>="=ru" means that the tag must contain "=ru" anywhere in > the value, "=ru$" at the end ... > As a regex is powerful but intimidating, lang=xx could be used as a shortcut > for the language convention, translating to the necessary regex. > > What is Jarry's patch doing? Jarry's patch is allowing people to use the <switch> statement combined with systemLanguage, to have per language customization of svgs. See http://www.w3.org/TR/SVG/struct.html#SwitchElement (Actually it just passes a language option to rsvg which renders svgs for us) To be honest, I think your bug makes more sense to dupe to bug 4688 then it does to dupe to this bug. I'll switch it to duping to that bug. (That said, I think it would be very unlikely to allow users to manipulate svgs using regexes on tag names. That's way more complex then we like user exposed interfaces to be, not to mention hard to guarantee that it would be performant in all situations)
I have commented the switch vs issue in bug 4688. (In reply to comment #9) > (That said, I think it would be very unlikely to allow users to manipulate > svgs > using regexes on tag names. That's way more complex then we like user exposed > interfaces to be, not to mention hard to guarantee that it would be > performant > in all situations) This is what I was saying: > (In reply to comment #8) > > As a regex is powerful but intimidating, lang=xx could be used as a shortcut > > for the language convention, translating to the necessary regex. regex could be used only internally, maybe access still allowed to geeks. But I'm not sure that sophisticated regex mapping is necessary.
I have written svg-sieve a script that does what bug 4688 suggests, select which layers to display, and by extension, bug 16052, select messages in a particular language. See bug 4688.
