Hey all, thanks for your replies. Unfortunately I wasn't able to read them until today, so the "official" GSoC proposal has now been sent off. That said, I'm no less enthusiastic about reaching out to knowledgeable people involved with translation, and, if necessary, adapting the way GSoC works out (if my proposal is accepted) or the future roadmap for TranslateSvg generally (if it is not).
So yes, comments still very much welcome :) I also have a few thoughts on what has been said already, and I'm hoping this can open up a dialogue (either on this list or bilaterally). Firstly, image "translation" isn't just (string) translation, which (as I understand it), is what the Translate extension focuses on. For example, it will involve users adjusting co-ordinates to ensure the image displays properly. It will involve changing formatting, including font size, and possibly bolding as well. It may even end up involving the selection of typefaces too. It will definitely involve an image preview. Is the architecture of the extension sufficiently high-level to accommodate these on a per-language basis, I wonder? If it is, then building on top of it sounds like a real possibility. Secondly, to respond to the question over Translatewiki.net, it is worth noting that the extraction and input of translatable strings into SVGs is non-trivial. If you imagine these as being hosted on Wikimedia Commons, a workflow taking in TranslateWiki.net would have, I think, to involve an intermediary storage area which TranslateWiki.net saves into, then a Wikipedia bot processing those, generating the new files and then uploading then daily/weekly onto Commons. That storage area would have to be populated by a second process. It's certainly doable, but it's tricky. Let's remember that there are 534,644 SVG files on Commons, suggesting that as many as 100,000 could end up being run through this process. Now, obviously, if we end up with 100,000s of new file versions uploaded, we are simply victims of our own success: but unlike interface translation it's not clear that even 1% of those updates will ever do any good at all - there's no known use case already in place. One solution could be to only pass SVGs being displayed in the "wrong" language on a wiki onto Translatewiki.net but, I'm keen that image translation be possible with immediacy. Although the lag-based process is neat, I would like casual users to be able to translate on-the-spot and with immediate effect, e.g. when they go to reuse a not-yet-translated SVG on their home wiki, without necessitating registration on Translatewiki.net and/or some kind of processing lag. There's probably a strong case for having *both* a local translation page - for casual users - *and* a Translatewiki.net process to allow for power translation. However, I would argue that the former is more important than the latter. To answer Gerard's query, I never intended the prototype to be properly reviewed, but it did generate an amount of attention and certainly fulfilled its role as a proof of concept. Regards, Harry (User:Jarry1250) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
