On Tue, Jun 19, 2012 at 4:09 PM, RGB ES <[email protected]> wrote: > 2012/6/19 Rob Weir <[email protected]>: > > > > 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 Unfortunately this project got halted but the needs are still there and the conversations are still unsolved.
