jarry1250 at gmail
Apr 8, 2012, 4:31 AM
Post #6 of 6
Re: GSoC -- TranslateSvg: Bringing the translation revolution to Wikimedia Commons
[In reply to]
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.
Wikitech-l mailing list
Wikitech-l [at] lists