(In reply to comment #0)

A single SVG file can contain the picture texts for many languages in layers
called e.g. nnn.language=ll.

Can it? I could only find a global "xml:lang" definition in http://www.w3.org/TR/SVG/struct.html#LangSpaceAttrs . Any link to the part of the specification?

Displaying a particular language is a matter of

its layers visibility. The [[File: syntax could contain "|language=ll" to
make the relevant SVG layers visible.

This sounds like a hack, plus which SVG editors in use would support creating numerous layers to "hide" string translations?

(In reply to comment #1)

(In reply to comment #0)

A single SVG file can contain the picture texts for many languages in layers
called e.g. nnn.language=ll.

Can it?

Yes it can. Layers is a basic functionality of SVG and I a often using it.

I could only find a global "xml:lang" definition in
http://www.w3.org/TR/SVG/struct.html#LangSpaceAttrs.

xml:lang doesn't seem designed to use multiple selectable texts, just to describe the language of some text.

Any link to the part of the specification?

A suggested "e.g." name that "would probably become a standard" has no link yet.

Displaying a particular language is a matter of

its layers visibility. The [[File: syntax could contain "|language=ll" to
make the relevant SVG layers visible.

This sounds like a hack,

Unclear.
What is a hack? What in what I say is one and in what way?
Please clarify.

plus which SVG editors in use would support creating numerous layers to "hide" string translations?

Plus, I'm using Inkscape, the number of layers doesn't seem to be limited and I very often keep text in a different layer(s). When I want to support another language, I clone that text layer, make the clone the only visible layer, and there I go translating it. Of course, I make only one language visible at a time and if I export the drawing to a PNG, only the visible layers are present. That is fundamental editor capabilities.
I have suggested Nikola Smolenski that his SVGTranslate could create layers.
The way I produce (export) a PNG file is the way I suggest a wiki could render a SVG. rsvg could support a lang= parameter.
Are you calling the authors of Inkscape hackers?

I made an experiment that is NOT the way it should be done but that shows the general idea.
I used a fun SVG made with inkscape and containing language text layers as described above.
<g

inkscape:groupmode="layer"
id="g3001"
inkscape:label="language=en"
style="display:none"
sodipodi:insensitive="true">

<text ...

<g

inkscape:groupmode="layer"
id="g3002"
inkscape:label="language=fr"
style="display:none"
sodipodi:insensitive="true">

<text ...

<g

inkscape:groupmode="layer"
id="g3004"
inkscape:label="language=ru"
style="display:none"
sodipodi:insensitive="true">

<text ...

...

Then I ran the following command with $svglan being the wanted language parameter
svglan=ru
perl -pe "undef $/; s/(\"layer\".*?language=$svglan.*?display:)none/\1inline/sg" source.svg | rsvg-convert > displayed.png

Et voilà, rsvg converts only the turned on "display:inline" layers and the result was a PNG in the chosen language.

Now, whether all editors can produce layers that way, or if the feature should be based on language-identified groups, I leave that discussion to persons having a wider SVG experience than me.
This is not an SVG specification (at least so far) but a convention to build a multilanguage SVG that Wikipedia, and hopefully other renderers, will display as such and that people are waiting for and will welcome.

In any case, the convention could be multiple (layer or group) and if an editor problem exists, a program like SVGTranslate could, in addition to show and make the texts in all the languages, normalize the SVG content to comply with the convention.

I have drawn keyboard layouts SVGs for Wikipedia and a similar problem raises. For example, a Russian keyboard is nothing more than a QWERTY keyboard with Cyrillic "stickers". Same for Greek. Same for the additions that Unix makes. Etc.
While we are at it, you might want to extend the convention to support those features to use a single SVG to maintain instead of a ménagerie.

In short, the SVG renderer receives parameters that turn various layers on based on their names or some ID.

Hoping to enhance Wikipedia.

André.

(In reply to comment #2)

called e.g. nnn.language=ll.

Can it?

Yes it can. Layers is a basic functionality of SVG and I a often using it.

I refered to "e.g. nnn.language=ll." and whether that is standardized in SVG, not to layers in general. :)

Any link to the part of the specification?

A suggested "e.g." name that "would probably become a standard" has no link
yet.

So we are talking about something that would require standardization first.

What is a hack?

https://en.wikipedia.org/wiki/Kludge#In_computer_science

Are you calling the authors of Inkscape hackers?

Of course. https://en.wikipedia.org/wiki/Hacker_%28programmer_subculture%29

(In reply to comment #3)

inkscape:label="language=en"
inkscape:label="language=fr"

This is not an SVG specification (at least so far)

It's a very interesting idea and approach, but as you say this needs to be more standardized, and get out of the "inkscape:" namespace. :)

Thanks for your interest.
standardization: as I said, this feature can only be a convention between Wikimedia and its users, but the wider spread the rendering of such an SVG file is, the better it is.
language: main usage indeed, but I also mentioned SVGs containing a layer mix to compose various keyboards. And SVGs have no limits.

The best place to tweak layer/group visibility is rsvg. It already checks element visibility and it's a matter of changing its mind.
At this interface the widest ("rawest") approach is the best, probably new command parameters that select which elements visibility has to be turned on, e.g. ongid=<regex> and onglabel=<regex> with regex supporting OR.
Wikimedia would decide in what form the user indicates his selection in the File: tag and translate it to the rsvc raw form.

"can only be" : I mean "can be only/just", not that it can't be a standard :-)

Looks like this has been requested already, see bug 16052.

• This bug has been marked as a duplicate of bug 16052 ***

Merge this into bug 4688 which is closer to the more general request of supporting various types of "layers"

(To be honest I don't think this is a good idea)

• This bug has been marked as a duplicate of bug 4688 ***