Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4FEF1E84.9050800@apache.org>
Date: Sat, 30 Jun 2012 17:43:00 +0200
From: Andrea Pescetti <pescetti@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Translation testing
References: 
 <CAP-ksoi6_aehjqSBTFaahEcZazCDQgemA75OKCo6OMdhmiphng@mail.gmail.com>
	<4FEEAF79.4000102@apache.org>
 <CAP-ksojjsvQ7rooJRi-zoWjbreNLdzwzL6HBTBNS1mdxQrEumw@mail.gmail.com>
In-Reply-To: 
 <CAP-ksojjsvQ7rooJRi-zoWjbreNLdzwzL6HBTBNS1mdxQrEumw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Rob Weir wrote:
> what level of quality is required to release something
> under the Apache OpenOffice name?

Unfortunately, it's very hard to put a threshold, also because it's a 
subjective matter.

> Three basic errors:
> 1) Formatting errors in translated strings that break some
> functionality of the program.

As you guessed, we already have tools to check this:
http://wiki.services.openoffice.org/wiki/Gsicheck
and they are probably still in use in the current process.
Note that an error may still slip in (example of a release blocker: the 
Italian team once accidentally translated two different styles using the 
same string; this broke styles handling in Writer, since Writer assumes 
that each style has a unique name) but it would really be an exceptional 
case.

> 2) Language errors in the translation.

Here it would help to have the builds out as soon as possible and tested 
by native speakers. But indeed this kind of problems are not blockers 
most of the times.

> 3) Errors in the core AOO code revealed by translation.

The main issue here is with the framework, which apparently forces to 
specify a length for string containers: it has happened quite often that 
the space allocated for a string had to be extended to accommodate 
translations. See for example
https://issues.apache.org/ooo/show_bug.cgi?id=117782
or directly the attachment:
https://issues.apache.org/ooo/attachment.cgi?id=76329

> #3 is more serious, but I think we solve it by having representative
> languages done early and more thoroughly reviewed, e.g., at least one
> BiDi language, at least one language with longer words than English
> (like German), at least one CJK language, etc.

OpenOffice.org had development builds only for German, French (as a 
language with longer strings, see problem above), Japanese (CJK 
language), Arabic (RTL) and Russian (non-Latin charset) as you can see here:
http://download.services.openoffice.org/files/extended/developer/DEV300m106/

Apache OpenOffice does much better, since it always provides the full 
language set for each development build. But we might want to promote 
development builds with more evidence to get early localization fixes.

Regards,
   Andrea.