[Tor www-team] Localization (passive vs active user interaction)

[Armin]

On 11.01.2014 23:40, Frithjof wrote:
> On Sat, Jan 11, 2014 at 6:42 PM, Armin <armin.baj at gmx.de> wrote:
> [...]
>>> But such an interface for translator could maybe be designed?
>> what are the requirements of the translators? maybe some translators are
>> around here and tell us about their workflow.
>> once we have the requirements we can start looking into our options
>> (transiflex, (vanilla or customized) pootle,  custom tool or something
>> different all together) and how good they fit those requirements.
>>
> I am actually way out of my knowledge domain here. I started doing
> translations recently and have been thinking about requirements since.
> I also tried to look around how other projects are handling
> translations. The problem is certainly not new, so if somebody knows
> about good solutions, please tell. There have to be some out there.
>
> The main question I see is: How can one make the translations survive.
>
> There already were translations once, but at some point many weren't
> maintained. This leads to some requirements that I think are
> important:
>
> * In a open-source project it is not clear that someone is caring for
> all the translations all the time. This might be possible in a
> commercial setting, but here it might happen that a translation is not
> maintained for some month, say, until a new maintainer shows up.
> (Maybe there even isn't a proper maintainer or team and all we can
> hope for is different people fixing and translating parts randomly.)
>
> Thus it is vital to be able to tell which translations are correct or
> up to date. Wrong documentation is worse than none (or only English
> documentation).  Using something like gettext solves this nicely.
> Outdated translations are marked fuzzy and are not used until they are
> corrected or confirmed. This way a translation can deteriorate in
> extend but now in correctness.
>
> * The translation needs to be sustainable in the sense that translator
> will leave and the entry barrier for new translator should be low.
> Even if a whole team closes down, it should be easy for others to
> inherit.
>
> Transifex helps here by making it really easy to get started and for
> example by having projects specific glossaries, so the knowledge and
> decisions of past translator is still available (or at least could
> be). Learning specialized tools and having commit access to some git
> repository instead already is quite a barrier.

i fully agree, the critical problem is to keep the translations up to date.
a low barrier of entry is certainly something to shoot for.

there are certain (already discussed) things we can do from the software
side of things,
like show outdated content (in context) and sending notifications about
new/changed content.
a glossary helps of course, as well as translation memory (both are
available in pootle and mediawiki:translate, i think).
but apart from those: not sure there is some magic sauce, that will help
to keep translations current.



now after some research (as in search engine usage) i want to bring up
mediawiki:translate [https://www.mediawiki.org/wiki/Extension:Translate].
Last time i looked at mediawiki itself i wasn't too impressed, but the
translation extension seems rather nice (without having actually played
with it).
they also have a workflow/ui spec at:
https://upload.wikimedia.org/wikipedia/commons/4/4a/Translate-workflow-spec.pdf
including a 'page' translation mode, which might be what is called for here:
https://commons.wikimedia.org/w/index.php?title=File:Translate-workflow-spec.pdf&page=6
https://commons.wikimedia.org/w/index.php?title=File:Translate-workflow-spec.pdf&page=19

mediawiki:translate is used at https://translatewiki.net to translate a
bunch of stuff.
integration between the site generator and mediawiki should also be
possible (converting between mediawiki syntax and e.g. markdown, if needed)

as tor already seems to be okay with using an external service for
translations:
maybe translatewiki.net is the answer (existing community, page
translation mode).


we should maybe start a simple matrix/table, so we can start to evaluate
the different tools. to narrow things down a bit and identify their pain
points.
i see the following categories:

* ease to get started
* glossary support
* support for translating paragraphs in context (and not just short strings)
* "advanced" CAT features (translation memory, online machine
translation lookup, etc.)
* "up-to-dateness" support (display of outdated content (in context),
notifications)
* review process support
* existing community
* user management/admin
* open source/able to customize, if needed
* integration effort (between site-generation and translation tool)
* ... and probably a bunch of other stuff i forgot

those categories need  some fleshing out, of course.

and on the tool axis
* transiflex
* pootle
* mediawiki:translate/translatewiki.net
* some other online CAT tool? (poeditor.com?)

then we can grade those in the defined categories (using grades from 1
to 10?  or maybe simply bad(-), mediocre(o) and good(+)).
i'm willing to setup a pootle and mediawiki:translate instance for
evaluation purposes, if there's interest.
each category should be graded by the same person, to keep grades
consistent.


>
>> anyway, i'm willing to put some time into making translations "work" (be
>> it integration scripts, hacking on pootle, help with a custom tool)
>>
> Id he am also interested in making this work, but I am far from being a
> web developer.
well, that's were i could help :-)