Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B0FEC950B for ; Wed, 28 Mar 2012 20:41:57 +0000 (UTC) Received: (qmail 51719 invoked by uid 500); 28 Mar 2012 20:41:57 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 51650 invoked by uid 500); 28 Mar 2012 20:41:57 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 51639 invoked by uid 99); 28 Mar 2012 20:41:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 20:41:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of marcus.mail@wtnet.de designates 213.209.103.13 as permitted sender) Received: from [213.209.103.13] (HELO smtp3.wtnet.de) (213.209.103.13) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 20:41:47 +0000 X-WT-Originating-IP: 84.46.106.163 Received: from f9.linux (pop8-672.catv.wtnet.de [84.46.106.163]) (authenticated bits=0) by smtp3.wtnet.de (8.14.4/8.14.4) with ESMTP id q2SKfRio010002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 22:41:27 +0200 Message-ID: <4F737777.8090602@wtnet.de> Date: Wed, 28 Mar 2012 22:41:27 +0200 From: "Marcus (OOo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: [RELEASE]: status update where we are and plan to move forward References: <4F72097A.6050609@googlemail.com> <4F7242A9.8090200@apache.org> <4F72B478.2010100@googlemail.com> In-Reply-To: <4F72B478.2010100@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Am 03/28/2012 08:49 AM, schrieb J�rgen Schmidt: > Hi Andrea, > > On 3/28/12 12:43 AM, Andrea Pescetti wrote: >> J�rgen Schmidt wrote: >>> A RC with en-US only is not really what our community is expecting. >> >> Exactly. >> >>> UI >>> We will include all languages where we have a 100% complete translation >>> for the UI (excepting the translation for the test automation tool like >>> for "ru") >>> HELP >>> For help I would not really rely on a 100% translation and would accept >>> >95%. >> >> These figures seem very high, we usually required > 80% (both UI and >> Help), see http://wiki.services.openoffice.org/wiki/Languages >> > > thanks for this feedback, I wasn't aware of this numbers and it seems > that my own expectations are higher than what we had before. I am open > for that and we can reduce the numbers but doesn't it make sense to have > 100% for UI and a lower number like the 80-85% for help. Help is not so > important from my point view (who never used help and preferred google) > but I think the UI should be complete. > > I am eager to learn from others and their experience and we should > define together some boundaries for the future. Let me allow to take a look into the past. ;-) OOo 3.3 Full install sets: This was done with 100 % for UI and Help with 100 - 0 % (e.g., we had never a translated Help in Arabic, however we have made a release for this language). There were also some exceptions with lower translation ratio because: the NL community was very eager with their L10N work and wanted to have a release somehow, the NL community had very good ratio in the past and exceptionally not this time, etc.). Langpacks: This was very less restrictive. Langpacks were done even with 0 % Help. The main focus was for the UI with a limit at ~80 %. General: http://wiki.services.openoffice.org/wiki/Release_criteria#Localization_requirements Finally, I recommend to *orientate* on these requirements: 100 - ~95 % UI and Help ratio for full install builds. 100 - ~80 % UI ratio for langpack builds. This is what our users know from past releases (at least from the Wiki or other posts) and would expect for the next release. Of course we can change the requirements. But only after more detailed discussions and a published outcome (e.g., in the Wiki, blog post). OOo 3.4 Beta Full install sets: Builds were done only for en-US. Langpacks: The ratios for the Beta release was a bit worse as IMHO the localization phase was not finished before the big stop. So, Sun/Oracle has shown a bit more flexibility and has released them anyhow. >> And, now that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is >> fixed (thanks!) the Italian version, even if at 95%-99%, would >> definitely be ready to ship. We will reach 100% anyway (Paolo knows more >> but there are more than a dozen vounteers so it won't be a problem for >> us), but I'm speaking in general: excluding a language at 95%-99% >> wouldn't make sense. +1 >> If there are concerns about problems in the translation process/data, >> then I'd prefer to distribute only builds for which we can identify a >> volunteer who takes care of testing that the translation is OK in the >> common use cases. > > Exactly that is what I have in mind we will only ship languages where > volunteers have shown up so far. > > Juergen +1 Marcus