Re: Ensuring Translation Quality

On Thu, Sep 22, 2011 at 7:52 AM, Urmas <davian818@gmail.com> wrote:
> To improve the translation quality I propose:
>
> 1) Remove .strings files for languages with translation less then 90% complete. We should preserve po-files in case somebody will want to improve them, obviously.

I posted my response to the first proposal already, I oppose an
arbitrary a quantitative 9percentage) cutoff.

> 2) Remove Esperanto [eo] translation entirely due to its low quality, and considering the fact that Esperanto is toy, artificial language, and quality translation can not be assured without contributors' voluntarism.

> 3) Remove Belarus (latin) translation entirely, as it is automatic and unofficial transliteration of standard Belarus spelling.

I cannot speak definitively to the quality of these translation;
however if they can be shown objectively to be of poor quality, then
it is fair to ask the contributors to examine the files and make an
argument for their inclusion.

I would potentially be in favor of dropping en_ie and en_AU if the
results of a poconflicts analysis show them to be adequately covered
by en-GB. en_GB would contain the main orthography differences from
en_US (color > colour) and the reality is that the limited vocabulary
of word-processor user interface is unlikely to differ significantly
as it is not rich in slang or other culturally-unique terms. I will
try to make time to do this but Sugar Labs is currently in string
freeze with a release date in the next few days, so things have been
busy.

http://wiki.sugarlabs.org/go/0.94/Roadmap#Schedule

I believe the most significant improvement that AbiWord can make in
it's translations is to re-base the PO files on those hosted in the
Pootle instance (they are easily downloaded) . During the upload and
review process, I discovered a number of strings which had been poorly
migrated in the past due to improper fuzzy matching. I made an effort
to flag these as "fuzzy" across all languages, to draw localizers
attention to them. Similarly, ther were a number fo printf errors
that I flagged as fuzzy, as printf errors can badly distort the
meaning of the string when used and in some cases have cause build
processes to fail (depending on the included level of error checking),
this happens in Sugar builds from time-to-time.

I believe the second most important translation "quality assurance"
step that the AbiWord project can take is to institute a published
release schedule process that includes several weeks of "string
freeze" in the UI to allow the localizers to catch up with the
development work. Something like the one at the link above for Sugar
Labs 0.94 release could be used as a model, but adjusted to AbiWord's
needs.

String freezes in FOSS projects are an important courtesy paid by
developers to localizers, and from long experience, I can tell you
that widely publicized "string freeze" periods tend to bring the
localizers out from the woodwork to polish their strings before
release. It has an tangible impact on creating a sense of ownership
within the L10n community over their strings and a shared sense of
responsibility for the quality of the release. The "string freeze"
creates period of community focus on the strings also tends to have an
impact on improving i18n of the original strings as localizers feel
empowered to ask questions about the meaning of ambiguous strings and
any clarifications needed are routinely approved as "string freeze
breaks".

Those are my thoughts on the topic of how to improve AbiWord
localizations and while they have mostly been garnered from my
experience with coordinating a diverse L10n community at Sugar Labs /
OLPC and also working to improve developer - L10n team communications
and collaboration. I believe these lessons are equally applicable to
AbiWord.

cjl
Sugar Labs Translation Team Coordinator
Received on Thu Sep 22 19:27:53 2011