openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [RELEASE]: new languages for AOO 3.4.1
Date Sat, 08 Dec 2012 13:32:53 GMT
On Dec 8, 2012, at 2:37 AM, janI <> wrote:

> On 8 December 2012 00:34, Rob Weir <> wrote:
>> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <>
>> wrote:
>>> On 04/12/2012 Rob Weir wrote:
>>>> We should introduce a disconnect here, to avoid 1 million
>>>> uses in Poland ignoring your easily ignored caveat and overwhelming
>>>> the server.
> If I may say so, the disconnect is already in place for the danish
> translation....and I am sure none of us like it. The danish forum has one
> simple solution, download LO. What is better that the people server get
> swammed (which might lead to a change in policy) or users give up !

This is a "false dichotomy". The third choice is "vote to release the

>>> This specific issue has now been solved by invoking policy (so, we will
>> be
>>> able to put builds on but we won't link to them from
>> the
>>> main website), but the problem is not here. The problem is that we have
>> had
>>> a Polish translation ready for months and that we haven't released it yet
>>> (even though recent improvements are really huge and will allow to avoid
>>> long waits in future).
> +1, 2 of the 3 danish volunteers (not including me) have more or less
> stopped working due to demotivation...we have not even been able to provide
> them with a running version to test their work until very recently.

This is not special to translators. Everyone who works hard on a new
feature or hard bug fix wants to see it quickly in the hands of users
as well.

>> So why haven't we released the Polish translation?  I agree that is a
>> problem, but not one that requires policy to change to solve.
>> Maybe releases under incubation were a pain the ass.  But the are
>> relatively easy now.  We should try it sometime...
>>> In general, and coming back to the main thread topic, if we have
>> millions of
>>> people who look for a certain language, we can find volunteers for that
>>> language, and your brilliant idea to put notices on the native-language
>>> websites proves it. So the problem is how to use our volunteers
>> effectively
>>> and motivate them. Ideally, I would like that it doesn't take more than
>> two
>>> months between the moment someone volunteers to complete a language and
>> the
>>> official availability of a build including his work.
>> Ergo, release more often.  This does not require any policy changes.
>> It just requires that we release more often.
> or at least just release of the language pack, which should be a lot easier
> to vote on (if needed).

The release procedure would be the same, but fewer binaries to
publish.   But it increases how many binaries the user needs to
download. So I'd release it all.

The real simplification would come if we could ever disentangle
platform dependencies from language packs. Today we have a language
pack, say, for Italian for Windows, another for Mac, another for
32-bit Linux, etc.  Why not just one?  Why do these even have platform

>>> If we try to motivate volunteers and to understand where the obstacles
>> are,
>>> we can probably make the "all languages" build virtually useless, since
>> all
>>> relevant languages will have been covered. I've just started a
>> discussion on
>>> ooo-l10n to check the status of the 19 extra translations for which
>> someone
>>> volunteered so far. I hope that this will also help in finding if the
>>> current policy can be improved: after all, OpenOffice has (probably) more
>>> committers than any other Apache project, it accounts for 40% of all
>> Apache
>>> web traffic (downloads excluded!) and if we identify clear problems with
>> the
>>> policy we can definitely initiate changes to it.
>> We just need to do some very simple things:
>> 1) When a translation is ready we need to test it.
> This should be, check pootle server review status, and have one volunteer
> send an e-mail, that the translation is ok.

We need some testing of real running code as well, not just visual
inspection of strings in Pootle. As you know the localization is more
than translation and we need to test the install and operations of
spell checker, etc.

So this step is really:

1a) notify Release Manager (or "Localization Build Lead"?) that
translation is ready.

1b) He builds and posts test build with new translation, dictionaries, etc.

1c) Community tests the test build, possibly iterating on these steps
if bugs are found.

1d) some way to sign-off on tested version to proceed to next step.

>> 2) When it is tested, we need to create 1) a source bundle containing
>> the changed source files, and a 2) a set of binary packages containing
>> the new installs.
>> 3) We have a 72 hour vote on the incremental source package

I'm assuming this step in uneventful, that all needed testing has been
done earlier. Until we have fully automated builds on all platforms,
step 2) requires manual coordination among several volunteers.   So we
don't want to be triggering that step too often. Otherwise that is

>> 4) If the vote passes then we put the new binaries on SourceForge, put
>> the new source bundle on the Apache mirrors, update the website and
>> send out an announcement.
> +1 to you procedure.
>> This is not hard.   Maybe some one-time upfront work to create
>> incremental language source bundles on demand.  It is certainly
>> simpler than trying to get a policy change.
>> Maybe it would help if someone volunteered to be Release Manager for
>> language releases between our numbered functional releases?  Then one
>> person can focus on the major builds, while another person focuses on
>> getting out these incremental translations.
> If I can get help to get started, I would like to volunteer for that part.
>> I think we can go a lot faster on new languages, but IMHO there is no
>> policy holding us back.  It is just work.
>> -Rob
>>> Regards,
>>>  Andrea.

View raw message