incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandro Colorado <>
Subject Re: Translation testing
Date Tue, 19 Jun 2012 21:30:33 GMT
On Tue, Jun 19, 2012 at 4:09 PM, RGB ES <> wrote:

> 2012/6/19 Rob Weir <>:
> >
> > If we want to have a reputation for high quality I think we need to
> > find a way to get beyond "solo translations", by which I mean
> > translations done by own person, with no independent review.
> >
> > We would never accept a code contribution in a language we could not
> > read or test, right?  We wouldn't ship an OS port if we didn't have
> > more than one user able to test it, would we?
> >
> > And look at existing translations.  Even though we are not really
> > changing the UI in 3.4.1 we're getting a stream of corrections to the
> > AOO 3.4.0 translations.  This is not surprising.   Errare humanum est.
> >  Even repetitive data transcription tasks can have a 5% error rate.
> > That's why where accuracy is important we have consistency checks, for
> > example checksum digits in credit card and ISBN numbers.  That's why
> > we do QA with code.  That is why we have spell checkers.
> >
> > It is almost guaranteed that a "solo translation" will have a higher
> > error rate.
> >
> > What can we do about this?
> >
> > Maybe we can promote the availability of a new translation, with help
> > from the translator, among our user base.  So notices on Twitter,
> > blogs, and native-language tech sites.  Invite users to download
> > snapshot builds with the goal of verifying the localization.   If  a
> > translation is worth doing we should be able to find a community (even
> > a small one) of users to help with this work.
> >
> > Any other ideas?
> >
> > Regards,
> >
> > -Rob
> >
> While lots of correction for the Spanish translation came just by
> checking the error tags on pootle (there is a way to go still...), a
> really impressive number are from direct interaction with forums users
> and volunteers, so I fully agree with all you said: by providing easy
> ways to share the user's concerns, helping them to participate, the
> results will always be good.
> But a common problem on open projects is the difficulty to find
> volunteers willing to spend some time not only checking the software
> (after all, "checking" is not different from "using"), but also
> *reporting* their findings: bugzilla in not for "normal users" and
> asking someone to register on a mailing list just to report a typo is
> a bit too much.
> So the challenge is to find paths to report translation problems on
> which "normal users" can feel comfortable. In my experience forums are
> a very good way, but we do not have (and probably will never have)
> forums for all localizations.
> Providing localized builds early on the development process (weeks or
> even a month before everything "freeze") would be a big help on this
> process. But we also need to provide accessible channels, both to
> advertise those builds and to report the findings.
> One consideration about the "early NL builds": we cannot ask our
> "casual testers" to make a full install of a beta software on a
> production machine. I think we should provide these early builds as
> "all in a folder" packages, just like the "arc" tarballs provided by
> the Linux build bot.
> Regards
> Ricardo

Users also dont understand the software cycle. So translation teams have
traditionally struggled with builders and QA teams to be able to fix the
problem and "Re-Release" the build.
Waiting for the next release is NOT a good answer for users or something a
suser would understand. This is why translation eventually was projecting
to do a  more real time fixing.
Continous l10n ws a project to fix this somewhat.

Unfortunately this project got halted but the needs are still there and the
conversations are still unsolved.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message