incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Translation testing
Date Wed, 20 Jun 2012 00:17:52 GMT
On Tue, Jun 19, 2012 at 5:30 PM, Alexandro Colorado <jza@oooes.org> wrote:
> On Tue, Jun 19, 2012 at 4:09 PM, RGB ES <rgb.mldc@gmail.com> wrote:
>
>> 2012/6/19 Rob Weir <robweir@apache.org>:
>> >
>> > 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.
> http://wiki.services.openoffice.org/wiki/ContinuousL10n

Crazy idea.  Would something like this work:

1) We do a one-time effort of getting screen shots of all dialogs and
other localized UI elements.

2) In Photoshop or Gimp, remove all the localized text

3) Take PO files and have a script generate a set of HTML pages that
display each of the UI screen shots, with the translated text
displayed in place.

4) HTML could also have links for each image that pre-populates a new
BZ issue to ease reporting of issues.

Is anything like this possible?

Benefits would be:

1) No need to wait for a build

2) Translation testers don't need to install a possibly unstable dev
snapshot build

3) Lowers the technical barriers to verifying translations.

I like your idea of doing continuous integration via language packs as well.

-Rob

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

Mime
View raw message