For an example of the problem, look at this typical image where the
existing source labels (here in French) are splitted into multiple
<tspan>'s : there's no easy way in the interface of translation (for
example here to Russian) to group these tspans according to their
parent <text> element, and allow a translation to group these tspans
in a <g> group for each language, these <g> groups being the real
members of a generated <switch> element which will be the new child of
the <text> element.
http://translatesvg.wmflabs.org/w/index.php?language=ru&title=Special%3…
Here, a structure like:
<text>
<tspan>...</tspan>
<tspan>...</tspan>
<text>
Will need to be converted first into:
<text>
<g lang="fr">
<tspan>...</tspan>
<tspan>...</tspan>
</g>
<text>
using some meta information requested to the first user converting the
SVG to a translatable version where this will be the correct first
language.
And then the multilingual version will be created by inserting the switch :
<text>
<switch>
<g systemLanguage="fr">
<tspan>...</tspan>
<tspan>...</tspan>
</g>
<switch>
<text>
(the source language is normally kept as the default fallback
language, the last in the switch). With this kind of layout, it will
be possible for a translation to add or remove tspans as necessary,
and to organize where line breaks will really appear, as their
translation may not match one for one at the <tspan> level, but only
at the <text> level.
Note also that the generated id's in the SVG for each successive
fallback in the list of child elements of the <switch> each time adds
a "fallback-" part before the new language code. This would create
overlong id's like:
tspan3065-fallback-fallback-fallback-fallback-fallback-fallback-fr
(see
http://translatesvg.wmflabs.org/w/images/5/53/Picturebook_3.svg,
and look at the SVG source to compare the generated IDs that are each
time longer for the child tspan of each <text> part of a switch)
The "fallback-" part should only appear in the generated ID on the
last child element of the switch. My opinion is that it is a bug of
the ID generator. But even in this case, the "fallback-" part is never
needed (look at the correct generated ID's for the parent <text> which
just appends the distinct language code to the original IDs (note also
that this simpler methods does not warranty that the generated ID will
be really distinct, unless the original ID's before starting the
translation to not create collision elsewhere.
Note also that the ":" character is allowed in an ID, and to make an
ID like "text528" unique after it is translation a naming convetion
similar to Wikimedia would generate ID's like "en:text528" with a
language code prefix: if an original ID already uses a colon, the
simpelst method to avoid collisions after the translation is to
convert all these original IDs by duplicating these original colons.
So if an original ID (in a SVG file without the language switch) is
something like ":xyz", its translatable ID will be changed first into
"::xyz" itself prefixed with the language code so it will start as
":fr:::xyz"; but if the orinal ID is "xyz:t" it is directly
translatable without other preprocessing by just prepending the prefix
":langcode:" as ":fr:xyz:t" without problem here because the oriignal
ID did not contain a leading colon ; there are a lot other possible
schemes to ensire ID's will remain unique while preserving much of the
original IDs in the members of the generated switches)
2012/8/5 Philippe Verdy <verdy_p(a)wanadoo.fr>fr>:
Tried tit but for being really usable to produce
translated images,
the Mediawiki thumbnail generator should be able to generate
translated versions of the images in distinct paths, by recognizing
the method used in the saved SVG file : the <switch> statement that is
using also a member element's property which matches the
"systemlocale".
Another problem for this method : the systemlocale is not necessarily
the one used to render pages in Mediawiki. Notably it will not match
the language selected in MediaWiki by the user account settings or by
navigating any page with the "uselang" query parameter.
If there a possibility of creating multiple distinct versions of the
SVG within the same HTTP "folder", using the untranslated image (or
the autotranslated page for the name of the parent folder, and the
same name of the language code for the child element, for both its
description page and the media page) ? Could it cause problems with
how images are currently named and saved in Wikimedia sites (for now
the "File:" namespace does not support folders, so the "/" in an
image
is part of the image name and this could create conflicts.
Are there other solutions for supporting translated images (also with
a "uselang" query parameter to get a SVG image without the language
switch but selecting the orrect labels, as well as a way to get the
PNG thumbnail generator to include the language code in the thumbnail
names, as well as creating separate histories, or an hostory filter
for each language)....
This will remain for now a Beta as long as the <switch> SVG feature is
not correctly supported in renderers and there's no easy way also to
indicate that by default the image should be rendered in the wiki's
default language if there's no user preferences for selecting the
corret language, and a way to navigate between languages (for example,
the history if these images shows thumbnails showing only the Englosh
version, and differences between versions are not visible when they
affect only one language which is not English, and no way to see the
other versions in the thumbnails of the history, plus no standard way
in browsers to select which language to display in a multilingual
SVG).
Full support of multilingual images, with a derived and cached
collection of autogenerated monolingual images seems to be the best
long term solution.
Finally it seems OK to allow a translation to change the display
font-size of even the font family (and the label positions), or to
drop some font styles (notably bold and italic), but it does not look
safe to allow a transaltion to add bold and italic styles, or to add
or remove the underlines.
Other attributes may also be necessary for RTL languages, because
sometimes a single label will be translated using multiple scripts
requiring bidirectional processing bplus Bidi overrides (new <tspan>
elements will be needed to split an existing label when translating
from English to Arabic for example, and in some cases it will also be
necessary to allow <tspans> to include more or less linebreaks with
<br> elements between <tspans>).
Note that changing font styles may impact applications like
cartographic maps, because all font styles have their own semantics
(for example making distinctions between major cities and minor
cities: if a label is too long, it may overlap other labels and a
choice will require to hide some other labels
