On Tue, Jun 19, 2012 at 5:30 PM, Alexandro Colorado <j...@oooes.org> wrote: > On Tue, Jun 19, 2012 at 4:09 PM, RGB ES <rgb.m...@gmail.com> wrote: > >> 2012/6/19 Rob Weir <robw...@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.
