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
