Support for multilingual SVGs
OpenPublic

Description

Author: claus.colloseus

Description:
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.


Version: unspecified
Severity: enhancement
URL: http://commons.wikimedia.org/wiki/Image:P-n_junction.svg
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58920

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz16052.
bzimport created this task.Via LegacyOct 20 2008, 5:13 PM
brion added a comment.Via ConduitOct 20 2008, 5:59 PM

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.

gpaumier added a comment.Via ConduitDec 31 2009, 6:26 PM

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.

gpaumier added a comment.Via ConduitDec 31 2009, 6:26 PM
  • Bug 15721 has been marked as a duplicate of this bug. ***
gpaumier added a comment.Via ConduitDec 31 2009, 6:26 PM
  • Bug 14320 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMar 12 2011, 8:37 PM

Bryan.TongMinh wrote:

(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?

Bawolff added a comment.Via ConduitOct 21 2013, 4:35 PM

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?

Aklapper added a comment.Via ConduitOct 21 2013, 7:50 PM
  • Bug 55768 has been marked as a duplicate of this bug. ***
A_Pirard added a comment.Via ConduitOct 21 2013, 10:15 PM

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?

Bawolff added a comment.Via ConduitOct 22 2013, 12:28 AM

(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)

A_Pirard added a comment.Via ConduitOct 22 2013, 7:03 PM

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.

A_Pirard added a comment.Via ConduitFeb 21 2014, 1:16 AM

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.

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:29 PM
Kozuch awarded a token.Via WebDec 17 2014, 8:06 PM

Add Comment