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