[Translators-l] TranslateSvg: beta version available for testing

[Philippe Verdy]

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