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. ***

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?

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.

(As suggested above: "it's better to discuss the implementation in one place")
There seems to be a relatively low limit on the lang selection (the drop-down menu). On some (greater) files there are no lang-selection appear:

• https://commons.wikimedia.org/wiki/File:LIGO_measurement_of_gravitational_waves.svg
• https://commons.wikimedia.org/wiki/File:Verwaltungsgliederung_%C3%96sterreichs.svg

The 380kB file in T212660

https://commons.wikimedia.org/wiki/File:German_territorial_losses_1919_and_1945.svg

is probably a victim of $wgSVGMetadataCutoff in https://doc.wikimedia.org/mediawiki-core/master/php/SVGMetadataExtractor_8php_source.html

As Perhelion notes above, some files do not display the dropdown language box. If MW does not find any systemLanguage attributes before the Cutoff, then MW believes there are not systemLanguage attributes and therefore no need to display a dropdown box.

Perhaps a similar interaction occurs when MW looks to include a file/image. If it does not find a systemLanguage, then it will display English. If the inclusion has an explicit lang=de, that test should be skipped. Clicking on an image with an explicit or implicit lang=de should add &uselang=de.