Extension talk:TranslateSvg/2.0

Preliminary RTL remarks
Looks good in general. Some general ideas about RTL:

My wild guess is that for most images the general orientation will remain and only the directionality of each string should be set. I don't really know SVG, so i won't embarrass myself by writing bad SVG, but i'll write it as if it was HTML:

And in Hebrew:

Note:
 * 1) I didn't change the dir of the root html element. This should be the default, but there can be an option to change it.
 * 2) I applied dir="rtl" to every changed element. Applying dir="rtl" probably makes this unnecessary, but it should be optional (see the previous point).
 * 3) I changed the lang attribute of the root element. AFAIK this attribute is applicable to SVG, and it must be used whenever possible. Applying it once to the root element should be enough. --Amir E. Aharoni (talk) 11:19, 2 May 2012 (UTC)
 * Hey Amir. The framework being used here in fact does limit us rather to only change things on a per-string basis (example with code). Thus, your post is indeed pertinent :) One issue though: because of that, you can't use "lang" globally (since global components such as shapes are not language specific), but only on a per-string basis. Then again, I'm not entirely sure that defining on a per-string basis is in fact desirable, because SVG allows you to optimise by having multiple languages display the same string (for example, many languages would be happy to leave untranslated the number "63"), a feature that would have to be abandoned in order to allow xml:lang to be implemented. Perhaps I've merely underestimated the importance of implementing xml:lang where systemLanguage (the attribute used to switch the display depending on language) already says (in semantic terms) "the following should be displayed to French-, German-, Spanish- and Norwegian-language readers", however? Hope that's not too unclear - the link should help if so. Thanks! Jarry1250 (talk) 14:16, 3 May 2012 (UTC)
 * Well, that's probably where my SVG ignorance kicks in :)
 * Basically what i'm saying is that explicitly specifying a language of any string is VERY useful. W3C expresses the importance of this quite well in its standards documents. It's useful for applying correct font, font size, hyphenation, spell-checking, line spacing, machine translation and many other things. In HTML documents it's already used quite widely, and should be used in SVG documents for the same reasons. How exactly should it be applied and on which elements - that's something that a person knowledgeable in SVG should decide.
 * Unfortunately, W3C standards explicitly say that directionality should NOT be deduced from language specification. I believe that the W3C is wrong in this regard and I am actively trying to convince the W3C to change this. Until it happens, rtl directionality must be applied explicitly to every relevant element. --Amir E. Aharoni (talk) 14:25, 3 May 2012 (UTC)
 * Yup, I'm with you. Actually, I realise I've actually misunderstood my own design, so I'm going to have another go at explaining the issues here.
 * Firstly, Wikimedia visitors for the foreseeable future are not going to actually be served SVGs, so it's only important that hte renderer understands how it's supposed to display things. Per string formatting control is enough to get that, I think.
 * There is some semantic value if SVGs were to be embedded directly (either on a different site, or in a couple of years no doubt on Wikimedia wikis); however, it would be limited to cases where the browser was embedding a language because it was the "default" but didn't otherwise know what language it was writing.
 * In other words, there is an argument here for having a particular language specified as the ultimate fallback - because SVGs could originate in any language, we won't necessarily know what language the default is in unless users tell us, unfortunately. But at least we can make sure we ask them :) Jarry1250 (talk) 14:48, 3 May 2012 (UTC)
 * Ask them, yes, by all means!
 * You can take a hint from the upload wizard: It gently asks for categories, but allows uploading if they aren't provided. In the latter case, the images are added to a "media without categories" category. Now that I think of it, the Upload Wizard asks for a description of an image and it asks to specify the language of the description, so almost all of the code that you need is already there.
 * Specifying a language of an SVG file is essential, because unlike software messages, which are almost always written in English, SVGs can be created in many different languages, so the user should be nudged to specify it. The Translate extension is supposed to be able to handle source languages other than English, but I'm not sure that this feature was actually used much, so it would be a cool opportunity to test it :) --Amir E. Aharoni (talk) 15:30, 3 May 2012 (UTC)