Re: Contacting i18n/l10n team

Hi there!

I am answering to an old email thread I found on the archive, after just 
joining the list.

I have experience configuring weblate, and I would like to give some 
information, without meaning to be confrontational:

> This needs to be decided per language team. I'm personally not fond of
> web based tools and anonymus contributions have not had the best
> quality in the past. And you cannot talk to the submitters at all.

Weblate has different levels of openness, and also has the possibility 
of requiring a review to add translations. It also has very powerful, if 
not widely used, QA checks. I can help to setup this checks, and I feel 
they help a lot for new translators to learn the ropes of a new setup to 
translate.
> 
> I think this is just lack of (wo)man power. Translation is important, but
> too few people take the time to prepare (good) translations and there
> is so much to translate. I would love to contribute to the web pages
> as well, but my resource are already bound to manpages-l10n and
> others.

I agree that more people is needed, but in my personal view the 
difficulty of some setups make the people unable to translate more. 
Weblate can help with integrating the work of not-so-technical people, 
while also helping more technical-minded people to save time.
> 
> From my manpages-l10n experience: Having a good infrastructure, trying
> to take care of the needs of translators, really helps.
> 
> So, in my opionion, what would really help is better education to the 
> english authors. If you only fix trivial (english) issues, e.g. commas, 
> quote signs, links, etc., then translators should not see it. So either 
> all up to date translations are bumped without change or the fix (e.g. 
> http → https) is done by the english author. This way, translators which 
> are up to date are releaved of work. And of course, separating trivial 
> and content updates. 

In weblate there are many options that can be configured to help with 
this issue. For example clear limits on what portion of the string needs 
to be translated, XML-valid checks, variants of strings, quick links to 
the upstream code or production site.

You can also enforce some QA checks so the translations do not reach the 
repository when said checks fail on a string.

You can also provide a bug reporting address that receives the comments 
people makes in weblate, have nice diff views of changes in strings, 
share translation memories between different projects.

And you can also enable translators to download and upload .po files if 
they feel more comfortable using poedit than the web interface.

I think weblate can be a good ally for translation if project admins 
spend some time giving context on the string, removing checks when they 
give false positives, and adding per-string and per-component flags. But 
sadly the configuration is a bit complicated and many projects are badly 
configured, which can be underwhelming.

Anyway, let me know if you are interested on this topics or you need 
help to configure a weblate instance, I would be happy to help.

You can also visit our translation project to see some of those features 
in place:

https://hosted.weblate.org/projects/tor/

emmapeel
Localization Coordinator
Tor Project