Ain, I voiced my opinion some weeks ago in a similar way, but was told there was once a language version that wouldn't run or install (I do not remember, was it Polish or French), so the only reason for QA voiced so far was that the localized build was horribly faulty, which means that it just needs to be tested if: a) it installs b) it runs c) it removes d) it opens and saves a file properly in the script used by the language For me all other tests are redundant - or could only be performed for representative languages, as I mentioned before, one Asian, one Latin, one Slavic, one Arabic etc. (or several of them, if they differ really that much). And with automatic testing getting better this could be done automatically by OpenOffice.org and the responsibility of L10n teams would just be to check error reports, if errors are reported - and recheck if they are related to the l10n they provide.
I also asked if SDF file testing can be made more bulletproof and so lower the number of tests needed to be made within QA. But well, my thinking was not received well. LP, m. 2009/11/19 Ain Vagula <avag...@gmail.com> > Followup to 'new home for downloads' thing. > Anyways when we take a look at list of approved and released packages > and rc-list and list with language packs only then it seems to me that > minority of teams are taking part in testing process at moment. Maybe > it could help, when these teams who have resources to do all tests, > register yourself for participating in localization QA and we could > figure out something for others without showing to world this weird > RCx stuff? > For example, when translation is submitted via IZ and merged later, > the submitter could verify the same issue itself to find out was the > merging made without any artefacts? Because these people know at best > which changes they made and can check it quickly. When OK, submitter > can say that translation was verified in test build and can be used in > final build (of course only for major releases, minor releases should > usually not require any interaction at all when no critical faults > were discovered). > Honestly I cannot imagine that faulty, bad or even crappy translation > could break the main functionality and stability of application. Sure > that applications based on earlier proprietary software (OpenOffice, > various *zillas & Sons) have invented a way to crash program, when > langpack of wrong version is installed (some mismatch of resources), > but it is not the case. > I have seen faulty fallbacks in OO.o when some localizable component > was missing (eg. to first or next language in alphabet instead of > English) but it is also not the case, even with P2 fixing these issues > takes 3 or more years. > Has someone an idea what really can happen that makes localized build > so dangerous? Is this something specific for RTL or CTL languages? Or > something specific for languages having poor support by operating > system? > I believe that wrong translations and typos (and even unmerged parts > of translation) we will still discover visually during in a quite long > time and more users could give us more feedback about such > inconstencies. > > ain > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org > For additional commands, e-mail: dev-h...@l10n.openoffice.org > >
