Re: [native-lang] Two days in Hamburg (QA and l10n meeting results)
Bert Meersma <[email protected]>
| Newsgroups | gmane.comp.openoffice.nativelanguage |
|---|---|
| Message-ID | <[email protected]> |
Hi Andre, Andre Schnabel wrote: >>> So some of the germanophone project members started to review all of >>> the german help files in November 05. So far, about 70% of the help >>> files have been reviewed. More than 50% of those files showed errors. >>> While the issues are only P3 or less in QA-terms, they ranged from >>> little to top priority for linguists. Top Priority means, that a >>> user was not able get a functionality working after reading the >>> file. And we had many of such errors. >>> Ok .. about 500 Issues have been filed so far, 450 are fixed (but >>> are not integrated yet). This amount could only be handled, because >>> a process for this task was discussed beforehand. >> I think this differs from our process, since we're collecting all >> errors in Calc sheets provided by Sun. Are we the only ones who work >> that way? > I think, you are speaking about the l10n-QA-matrix? Afaik, Italian > community worked with that. > We had a look at the matrix, but after all, it didn't fit our needs, > as it's focus is translation. But we found a horrible mixture of errors: > - Typos > - Translation errors > - Inconsitencies in the UI > - old strings (that have been absolutely correct translated and caused > the most troubles) > - Errors in english help I'm indeed speaking of the QA matrix. But we are not using it as it was intended for exactly the same reasons you mentioned here. Filling in the complete matrix would be an undoable job this way. Perhaps in the future when we have a GUI and OLH of acceptable quality we go deeper into this. > >> >>> A second possible task would be a review of the german UI-Strings, >>> as they are inconsistend in several cases. >> We started with the UI strings. Reason for that is that if you change >> UI strings you also have to change the help files. Starting off with >> a "sound" UI prevents you from having to edit a lot help files >> afterwards. > > We knew about some inconsistend UI-stings when we started the help > review. But we found even more during the review. For the moment, we > need skip such problems in the help review, mark them for UI review > and then come back again. > If we had unlimited ressources, we could do the UI review right now .. > but .. well, I think, you know the problems ;-) I found that the UI review didn't take nearly as much time as the OLH review does, wich is logical since the OLH has many more strings to review. And we didn't have a perfect GUI after the review. We still found errors during the OLH review. But I'm confinced it saved us much time during the OLH review. > > > BTW.: Rafaella was telling about the nl commuity as a example and > reference for Sun - community - vendor colaboration in localisation. > So .. maybe we can learn from you :-) The most important thing in such a collaboration is clear communication. It should to be clear to everybody who does what, when and how. Regards, Bert -- __________________________________________________ Broxtor on irc.freenode.net (#nl.openoffice.org)