You are viewing a plain text version of this content. The canonical link for it is here.
Posted to l10n@openoffice.apache.org by Jürgen Schmidt <jo...@gmail.com> on 2012/12/04 13:39:59 UTC
[RELEASE]: new languages for AOO 3.4.1
Hi,
based on some earlier discussion I think we have reached more common
consensus that we 1. want release further languages for AOO 3.4 1 and 2.
how we can do that.
To make it more concrete I have created a new wiki page [1] where I
would like to document the release process, the proposed release
schedule, how the new translation will be integrated etc.
The page is not yet complete and we can add further information on
demand. Please help me to document the issues, references to
dictionaries etc.
I propose to extend the deadline a little bit to reflect the holidays
and the new year's day.
Proposed release schedule:
- translation deadline, January 4th, 2013.
All new translation have to be available as attachment to a new related
issue for each language.
- availability of 1. developer snapshots, January 11th, 2013
- potential 2. developer snapshots, January 25th, 2013
- GA, January 31th, 2013
Any opinions, concerns or feedback? Follow up discussion should take
place on the dev list only (the list where decisions are made).
Juergen
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Respin+for+additional+languages
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Wed, Dec 5, 2012 at 7:12 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> On Tue, Dec 04, 2012 at 05:55:53PM -0500, Rob Weir wrote:
>> And btw, just so you can see that I'm not just making stuff up, please
>> note the ASF Releases Policy page:
>>
>> "What Is A Release?
>
> [...]
>
>> http://www.apache.org/dev/release.html
>>
>> Hopefully that is clearer than my unsuccessfully attempts at explaining this.
>
> None of which applies to what I originally intended to say: replace
> people.apache.org with apache-extras, dropbox, or whatever; it's simply
> the same as what I started doing by the end last year/beginning of these
> year providing the first binaries packages, now applied only to language
> packs. It won't be something published, the general public won't be
> instructed to download them.
>
Uh, you're the one who brought up your Linux-glibc2.5 work, not I.
That work was done in your name and is on the porting page, with a
suitable disclaimer. Aside from the use of people.apache.org I don't
see a problem here. If there is a bandwidth concern that is between
you and Infra.
But with the language builds, this is something else. If they are to
be useful they need to be updated, Maybe they start identical to
3.4.1, at 80% or whatever. But as work progresses, to 85%, 95%, 995,
etc., we need them refreshed for continued testing. So this does then
become pre-release software and falls under existing ASF policy. Of
course, you are free to take pre-release code and post it on some
other website, but I'd oppose linking to it from project websites.
Regards,
-Rob
> So far I only planned this for Linux-glibc2.5, I may build also for
> Windows, but not for MacOS.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Dec 04, 2012 at 05:55:53PM -0500, Rob Weir wrote:
> And btw, just so you can see that I'm not just making stuff up, please
> note the ASF Releases Policy page:
>
> "What Is A Release?
[...]
> http://www.apache.org/dev/release.html
>
> Hopefully that is clearer than my unsuccessfully attempts at explaining this.
None of which applies to what I originally intended to say: replace
people.apache.org with apache-extras, dropbox, or whatever; it's simply
the same as what I started doing by the end last year/beginning of these
year providing the first binaries packages, now applied only to language
packs. It won't be something published, the general public won't be
instructed to download them.
So far I only planned this for Linux-glibc2.5, I may build also for
Windows, but not for MacOS.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Dec 4, 2012 at 5:44 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Dec 4, 2012 at 4:31 PM, Ariel Constenla-Haile
> <ar...@apache.org> wrote:
>> On Tue, Dec 04, 2012 at 03:00:13PM -0500, Rob Weir wrote:
>>> >> If we want something to be downloaded and used by the public then we
>>> >> should release it, period. We should not be looking for clever ways
>>> >> to avoid the important release steps of verifying IP, producing a
>>> >> source package and voting on it.
>>> >
>>> > It seems you are mixing things, as I only proposed to build all language
>>> > packages, while following the same release criteria as before (release
>>> > only languages with 100% UI and a localization team backing it). Where
>>> > do you see a clever way to avoid official procedures in this?
>>> >
>>>
>>> When you suggested that we point users to these un-released binaries.
>>
>> Well, this meant only: If a user sends a mail telling that AOO does not
>> work on his RHEL 5 system, I find it good to point her/him to the
>> packages I've made, this will solve her/his problem. So if I read the
>> mail, I will point her/him to my packages. The same would apply in this
>> case with the language packs (which I already plan to do for the
>> linux-glib-2.5 build).
>>
>> I didn't mean to "officially" point the users (whatever that could
>> mean).
>>
>
> I think your little project is less of a practical concern. It
> probably doesn't use much bandwidth. The much larger danger is that
> we mention a new translation on the public website, and that gets
> mentioned on a popular website, or social media, or a magazine and all
> of a sudden we get massive download requests going to
> people.apache.org. Do you really want to see Infra get upset?
> Remember, the ASF has limited bandwidth.
>
> We cannot control this or prevent it from happening. It is out of our
> control once we mention something on the pubic website. So we need to
> act responsibly. And that means (IMHO) that if we're producing a test
> build for QA and NL people to test with, that we publicize only as
> much as needed for them to know that it exists. That means the
> mailing lists. We need to be aware of how big the AOO project is, in
> comparison to the rest of the ASF, and take such precautions if we
> want to stay welcome here.
>
And btw, just so you can see that I'm not just making stuff up, please
note the ASF Releases Policy page:
"What Is A Release?
Releases are, by definition, anything that is published beyond the
group that owns it. In our case, that means any publication outside
the group of people on the product dev list. If the general public is
being instructed to download a package, then that package has been
released. Each PMC must obey the ASF requirements on approving any
release. How you label the package is a secondary issue, described
below.
During the process of developing software and preparing a release,
various packages are made available to the developer community for
testing purposes. Do not include any links on the project website that
might encourage non-developers to download and use nightly builds,
snapshots, release candidates, or any other similar package. The only
people who are supposed to know about such packages are the people
following the dev list (or searching its archives) and thus aware of
the conditions placed on the package. If you find that the general
public are downloading such test packages, then remove them.
Under no circumstances are unapproved builds a substitute for
releases. If this policy seems inconvenient, then release more often.
Proper release management is a key aspect of Apache software
development.
The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released. In some cases, binary/bytecode
packages are also produced as a convenience to users that might not
have the appropriate tools to build a compiled version of the source.
In all such cases, the binary/bytecode package must have the same
version number as the source release and may only add binary/bytecode
files that are the result of compiling that version of the source code
release."
http://www.apache.org/dev/release.html
Hopefully that is clearer than my unsuccessfully attempts at explaining this.
Regards,
-Rob
>>> > In the end, it's just the same as I've done with the linux glib-2.5
>>> > build, which is advertised in the portings page, and stored at
>>> > people.apache.org... I haven't heard any complaints about this, so far
>>> > only some people thankful
>>> > https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13
>>> >
>>>
>>> Perhaps we should start looking at such pseudo releases more carefully?
>>
>> I don't see the point, these are not (pseudo) releases, they are simply
>> community contributed packages, that might be useful for some users. The
>> same aipplies to adfinis solaris builds, and any other "unofficially"
>> community contributed stuff.
>>
>
> But these are not on people.apache.org, are they?
>
> -Rob
>
>>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Dec 4, 2012 at 4:31 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> On Tue, Dec 04, 2012 at 03:00:13PM -0500, Rob Weir wrote:
>> >> If we want something to be downloaded and used by the public then we
>> >> should release it, period. We should not be looking for clever ways
>> >> to avoid the important release steps of verifying IP, producing a
>> >> source package and voting on it.
>> >
>> > It seems you are mixing things, as I only proposed to build all language
>> > packages, while following the same release criteria as before (release
>> > only languages with 100% UI and a localization team backing it). Where
>> > do you see a clever way to avoid official procedures in this?
>> >
>>
>> When you suggested that we point users to these un-released binaries.
>
> Well, this meant only: If a user sends a mail telling that AOO does not
> work on his RHEL 5 system, I find it good to point her/him to the
> packages I've made, this will solve her/his problem. So if I read the
> mail, I will point her/him to my packages. The same would apply in this
> case with the language packs (which I already plan to do for the
> linux-glib-2.5 build).
>
> I didn't mean to "officially" point the users (whatever that could
> mean).
>
I think your little project is less of a practical concern. It
probably doesn't use much bandwidth. The much larger danger is that
we mention a new translation on the public website, and that gets
mentioned on a popular website, or social media, or a magazine and all
of a sudden we get massive download requests going to
people.apache.org. Do you really want to see Infra get upset?
Remember, the ASF has limited bandwidth.
We cannot control this or prevent it from happening. It is out of our
control once we mention something on the pubic website. So we need to
act responsibly. And that means (IMHO) that if we're producing a test
build for QA and NL people to test with, that we publicize only as
much as needed for them to know that it exists. That means the
mailing lists. We need to be aware of how big the AOO project is, in
comparison to the rest of the ASF, and take such precautions if we
want to stay welcome here.
>> > In the end, it's just the same as I've done with the linux glib-2.5
>> > build, which is advertised in the portings page, and stored at
>> > people.apache.org... I haven't heard any complaints about this, so far
>> > only some people thankful
>> > https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13
>> >
>>
>> Perhaps we should start looking at such pseudo releases more carefully?
>
> I don't see the point, these are not (pseudo) releases, they are simply
> community contributed packages, that might be useful for some users. The
> same aipplies to adfinis solaris builds, and any other "unofficially"
> community contributed stuff.
>
But these are not on people.apache.org, are they?
-Rob
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Dec 04, 2012 at 03:00:13PM -0500, Rob Weir wrote:
> >> If we want something to be downloaded and used by the public then we
> >> should release it, period. We should not be looking for clever ways
> >> to avoid the important release steps of verifying IP, producing a
> >> source package and voting on it.
> >
> > It seems you are mixing things, as I only proposed to build all language
> > packages, while following the same release criteria as before (release
> > only languages with 100% UI and a localization team backing it). Where
> > do you see a clever way to avoid official procedures in this?
> >
>
> When you suggested that we point users to these un-released binaries.
Well, this meant only: If a user sends a mail telling that AOO does not
work on his RHEL 5 system, I find it good to point her/him to the
packages I've made, this will solve her/his problem. So if I read the
mail, I will point her/him to my packages. The same would apply in this
case with the language packs (which I already plan to do for the
linux-glib-2.5 build).
I didn't mean to "officially" point the users (whatever that could
mean).
> > In the end, it's just the same as I've done with the linux glib-2.5
> > build, which is advertised in the portings page, and stored at
> > people.apache.org... I haven't heard any complaints about this, so far
> > only some people thankful
> > https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13
> >
>
> Perhaps we should start looking at such pseudo releases more carefully?
I don't see the point, these are not (pseudo) releases, they are simply
community contributed packages, that might be useful for some users. The
same aipplies to adfinis solaris builds, and any other "unofficially"
community contributed stuff.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ra...@gmail.com>.
On Dec 4, 2012, at 2:53 PM, Ariel Constenla-Haile <ar...@apache.org> wrote:
> On Tue, Dec 04, 2012 at 02:13:49PM -0500, Rob Weir wrote:
>>>>>> Any opinions, concerns or feedback? Follow up discussion should take
>>>>>> place on the dev list only (the list where decisions are made).
>>>>>
>>>>> It may be a good idea to build all languages, or at least those with 80%
>>>>> of the UI translated, but release only those with 100%; we could leave
>>>>> the rest in people.apache.org as unofficial builds (at least langpacks),
>>>>> and point people to them instead of you-know-what http://s.apache.org/yY
>>>>
>>>> We can't do that. We either release or we don't release a language.
>>>> If we're not releasing it then we should not be pointing users to it
>>>> on people.apache.org. This is an issue both from Apache release
>>>> policy and Infra policy (bandwidth issues).
>>>
>>> Change people.apache.org for apache-extras or any other place. The idea
>>> is having all language packs built, not advertising them on our website
>>> (that said, note that the dev. snapshots hosted on people.apache.org are
>>> advertised on the main download page ;) ). And the goal is to point them
>>> to user when they ask, or list them on the porting page, or using them
>>> for ongoing translation efforts, etc.
>>
>>
>> If we want something to be downloaded and used by the public then we
>> should release it, period. We should not be looking for clever ways
>> to avoid the important release steps of verifying IP, producing a
>> source package and voting on it.
>
> It seems you are mixing things, as I only proposed to build all language
> packages, while following the same release criteria as before (release
> only languages with 100% UI and a localization team backing it). Where
> do you see a clever way to avoid official procedures in this?
>
When you suggested that we point users to these un-released binaries.
> In the end, it's just the same as I've done with the linux glib-2.5
> build, which is advertised in the portings page, and stored at
> people.apache.org... I haven't heard any complaints about this, so far
> only some people thankful
> https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13
>
Perhaps we should start looking at such pseudo releases more carefully?
> If I have the time, and the will to do so with the language packs, there
> is nothing that prevents me for doing so.
>
>> This is what it means to be an Apache project.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Dec 04, 2012 at 02:13:49PM -0500, Rob Weir wrote:
> >>>> Any opinions, concerns or feedback? Follow up discussion should take
> >>>> place on the dev list only (the list where decisions are made).
> >>>
> >>> It may be a good idea to build all languages, or at least those with 80%
> >>> of the UI translated, but release only those with 100%; we could leave
> >>> the rest in people.apache.org as unofficial builds (at least langpacks),
> >>> and point people to them instead of you-know-what http://s.apache.org/yY
> >>
> >> We can't do that. We either release or we don't release a language.
> >> If we're not releasing it then we should not be pointing users to it
> >> on people.apache.org. This is an issue both from Apache release
> >> policy and Infra policy (bandwidth issues).
> >
> > Change people.apache.org for apache-extras or any other place. The idea
> > is having all language packs built, not advertising them on our website
> > (that said, note that the dev. snapshots hosted on people.apache.org are
> > advertised on the main download page ;) ). And the goal is to point them
> > to user when they ask, or list them on the porting page, or using them
> > for ongoing translation efforts, etc.
> >
>
>
> If we want something to be downloaded and used by the public then we
> should release it, period. We should not be looking for clever ways
> to avoid the important release steps of verifying IP, producing a
> source package and voting on it.
It seems you are mixing things, as I only proposed to build all language
packages, while following the same release criteria as before (release
only languages with 100% UI and a localization team backing it). Where
do you see a clever way to avoid official procedures in this?
In the end, it's just the same as I've done with the linux glib-2.5
build, which is advertised in the portings page, and stored at
people.apache.org... I haven't heard any complaints about this, so far
only some people thankful
https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13
If I have the time, and the will to do so with the language packs, there
is nothing that prevents me for doing so.
> This is what it means to be an Apache project.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 12/4/12 10:56 PM, Andrea Pescetti wrote:
> On 04/12/2012 Rob Weir wrote:
>> On Dec 4, 2012, at 1:46 PM, Ariel Constenla-Haile wrote:
>>> having all language packs built, not advertising them on our website
>>> (that said, note that the dev. snapshots hosted on people.apache.org are
>>> advertised on the main download page ;) ). And the goal is to point them
>>> to user when they ask, or list them on the porting page, or using them
>>> for ongoing translation efforts, etc.
>
> This is a very good idea. Actually, I probably proposed it myself on
> ooo-l10n a few months ago... But I really think that this can be an
> extremely useful resource for prospective translators, and for the image
> of the project in general.
>
>> If we want something to be downloaded and used by the public then we
>> should release it, period. We should not be looking for clever ways
>> to avoid the important release steps of verifying IP, producing a
>> source package and voting on it. This is what it means to be an
>> Apache project.
>
> We have plenty of ways to differentiate these from the packages we make
> available from our download page: we could make a (monster-sized)
> "multilingual build" instead of individual langpacks; we can rename the
> product and make an "OOO-DEV" build; we can provide an "archive" build
> (i.e., zipfiles with no installation).
>
> I see the workflow this way:
> - A user opens pl.openoffice.org and finds that Polish is not available
> - A warning on that page takes him to a "Your help is needed" page
> - This page provides information on how to help with translations in
> general, plus a link to the "experimental build" above where the user
> can see the current level of support for Polish
> - Yes, someone might download the build and be OK with it, but we will
> possibly gain translation volunteers, and they will be more motivated by
> seeing in practice what "95% translated" means. And, of course, this
> build will be very helpful for them when translating, so that they can
> use it to see existing terminology and put untranslated strings in context.
>
> The download page other.html would contain something like "If you don't
> see your language here, help us to get it released!" and link to the
> "Your help is needed" page above.
>
> An important clarification: these sources have already been voted upon.
> I can build the 3.4.1 sources from August with "--with lang=pl" and get
> OpenOffice in Polish (well, 95% Polish and 5% English). So this is just
> a build of OpenOffice 3.4.1 from the verified, voted and released sources.
I am not sure if we really have updated all sdf files for all languages
or only on demand for the languages we planned to release.
Before we build all languages and put them in whatever space we should
verify this and and should of course do a minimal test (build
verification test or something like this) on these languages. Who will
do that? I am personally are more motivated to support interested
volunteers with their tongue language when they are willing to help.
And I believe that when we include new languages on demand only in our
dev snapshots when we see active volunteers interested doing the
translation it is the better approach to motivate people.
Look for example Arabic, we include it in the first release because we
thought it is important. We had some new error messages to translate but
no volunteers. Ok we probably didn't tried enough to find them but it
was and is dangerous in general when we don't have communities behind a
language. What should we do for a new release with more UI changes that
needs translation, drop the languages again?
I am in favor of keeping the current approach and include new languages
only on demand when we see an active translation community (at least one
person able to make changes ;-))
For AOO 4.0 I will definitely update all languages to solve some already
existing changes in the resources and I expect more. But for 3.4.1 I
have no plans to change anything here.
In the future when we have 100% known state I can think of one
multi-language binary for testing and verification of languages.
Juergen
>
> Regards,
> Andrea.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Dec 08, 2012 at 08:32:53AM -0500, Rob Weir wrote:
> 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
> dependencies.
Assuming that the content is platform-independent (I didn't check this),
the main reason is that language packs are installable, and there is no
universal install mechanism, the installation/removal is done using the
standard system procedures.
The solution here seems to make the language packs not
system-installable, but installed by the application, as if they where
extensions.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Andrew Rist <an...@oracle.com>.
On 12/10/2012 1:16 AM, Jürgen Schmidt wrote:
> On 12/8/12 8:36 AM, janI wrote:
>> On 8 December 2012 00:34, Rob Weir <ro...@apache.org> wrote:
>>
>>> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <pe...@apache.org>
>>> 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 people.apache.org 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 specific issue has now been solved by invoking policy (so, we will
>>> be
>>>> able to put builds on people.apache.org 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.
> communication is key here and people can ask again and again if nothing
> happened in time. We have so many things to do that it is often not easy
> to make it right for everybody.
>
> I would like to see everything more automated but even that needs time
> and people who work on it.
>
> Andrew and Herbert improved the build bots a lot (ok MacOS bot is still
> missing) and you can easy find the result under
> http://ci.apache.org/projects/openoffice/
>
> The windows configuration is very close to our release configuration (no
> binfilter) and should be perfect for testing of translations.
>
> For the Danish translation for example I have updated Pootle and trunk
> immediately after receiving the files. Everybody would have been able to
> build it on trunk. Ok some strings are moved now and the translation
> needs some tweaks as all other translations as well.
>
> I am also sometimes demotivated because things didn't worked as expected
> but I don't stop trying to make it better.
>
> Juergen
It is very easy to add a language to the build. I think we are moving
in the direction of having a us+de build for the nightlies, with the
snapshot build covering the full set of languages. If there is a
language in the source tree that is not being built and should be,
please send a message to dev@ and we'll add it in. Additionally, we
should look at running the po2sdf step during the snapshot build, so
that only the check-in of a po file is required to get the changes in.
Andrew
>
>>> 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).
>>
>>>> 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.
>>
>>> 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
>>>
>>> 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.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 12/8/12 8:36 AM, janI wrote:
> On 8 December 2012 00:34, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <pe...@apache.org>
>> 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 people.apache.org 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 specific issue has now been solved by invoking policy (so, we will
>> be
>>> able to put builds on people.apache.org 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.
communication is key here and people can ask again and again if nothing
happened in time. We have so many things to do that it is often not easy
to make it right for everybody.
I would like to see everything more automated but even that needs time
and people who work on it.
Andrew and Herbert improved the build bots a lot (ok MacOS bot is still
missing) and you can easy find the result under
http://ci.apache.org/projects/openoffice/
The windows configuration is very close to our release configuration (no
binfilter) and should be perfect for testing of translations.
For the Danish translation for example I have updated Pootle and trunk
immediately after receiving the files. Everybody would have been able to
build it on trunk. Ok some strings are moved now and the translation
needs some tweaks as all other translations as well.
I am also sometimes demotivated because things didn't worked as expected
but I don't stop trying to make it better.
Juergen
>
>>>
>>
>> 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).
>
>>
>>> 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.
>
>>
>> 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
>>
>> 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.
>>
>
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ra...@gmail.com>.
On Dec 8, 2012, at 2:37 AM, janI <ja...@apache.org> wrote:
> On 8 December 2012 00:34, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <pe...@apache.org>
>> 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 people.apache.org 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
translation".
>
>>>
>>>
>>> This specific issue has now been solved by invoking policy (so, we will
>> be
>>> able to put builds on people.apache.org 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
dependencies.
>>
>>> 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
demotivating.
>> 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.
>>
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by janI <ja...@apache.org>.
On 8 December 2012 00:34, Rob Weir <ro...@apache.org> wrote:
> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <pe...@apache.org>
> 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 people.apache.org 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 specific issue has now been solved by invoking policy (so, we will
> be
> > able to put builds on people.apache.org 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.
> >
>
> 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).
>
> > 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.
>
> 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
>
> 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.
>
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti <pe...@apache.org> 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 people.apache.org server.
>
>
> This specific issue has now been solved by invoking policy (so, we will be
> able to put builds on people.apache.org 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).
>
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.
> 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.
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
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.
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.
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.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Andrea Pescetti <pe...@apache.org>.
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 people.apache.org server.
This specific issue has now been solved by invoking policy (so, we will
be able to put builds on people.apache.org 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).
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.
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.
Regards,
Andrea.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Dec 4, 2012 at 4:56 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 04/12/2012 Rob Weir wrote:
>
>> On Dec 4, 2012, at 1:46 PM, Ariel Constenla-Haile wrote:
>>>
>>> having all language packs built, not advertising them on our website
>>> (that said, note that the dev. snapshots hosted on people.apache.org are
>>> advertised on the main download page ;) ). And the goal is to point them
>>> to user when they ask, or list them on the porting page, or using them
>>> for ongoing translation efforts, etc.
>
>
> This is a very good idea. Actually, I probably proposed it myself on
> ooo-l10n a few months ago... But I really think that this can be an
> extremely useful resource for prospective translators, and for the image of
> the project in general.
>
>
>> If we want something to be downloaded and used by the public then we
>> should release it, period. We should not be looking for clever ways
>> to avoid the important release steps of verifying IP, producing a
>> source package and voting on it. This is what it means to be an
>> Apache project.
>
>
> We have plenty of ways to differentiate these from the packages we make
> available from our download page: we could make a (monster-sized)
> "multilingual build" instead of individual langpacks; we can rename the
> product and make an "OOO-DEV" build; we can provide an "archive" build
> (i.e., zipfiles with no installation).
>
We can certainly do this, but we cannot stick them on
people.apache.org and then have 1 million people in Sweden start
downloading them. We can create dev builds for our own use and for
testing, but when we start pointing users to them -- users, not
project members -- then that is called "publishing software" and we
need to do this in the framework of a release.
> I see the workflow this way:
> - A user opens pl.openoffice.org and finds that Polish is not available
> - A warning on that page takes him to a "Your help is needed" page
> - This page provides information on how to help with translations in
We already do the above.
> general, plus a link to the "experimental build" above where the user can
> see the current level of support for Polish
I disagree. We should introduce a disconnect here, to avoid 1 million
uses in Poland ignoring your easily ignored caveat and overwhelming
the people.apache.org server.
For example, do as do do right now -- point them to an info page on
how to get involved with translation. Then when they join the L10n
list we can point them to the test build.
> - Yes, someone might download the build and be OK with it, but we will
> possibly gain translation volunteers, and they will be more motivated by
> seeing in practice what "95% translated" means. And, of course, this build
> will be very helpful for them when translating, so that they can use it to
> see existing terminology and put untranslated strings in context.
>
I agree with gaining translators. But let's not take the very
reasonable and basic precaution of not publisizing the unreleased test
builds on people.apache.org *until* the volunteers have actually
joined the list.
> The download page other.html would contain something like "If you don't see
> your language here, help us to get it released!" and link to the "Your help
> is needed" page above.
>
> An important clarification: these sources have already been voted upon. I
> can build the 3.4.1 sources from August with "--with lang=pl" and get
> OpenOffice in Polish (well, 95% Polish and 5% English). So this is just a
> build of OpenOffice 3.4.1 from the verified, voted and released sources.
>
But the binaries have not been released. If you want to release them
then you know what needs to be done. They need to get onto Apache
mirrors and/or SourceForge and we point users to that. I would have
no objections to that. But I do object to publicizing to public
visitors www.openoffice.org the existence of unreleased test builds on
people.apache.org.
-Rob
> Regards,
> Andrea.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Andrea Pescetti <pe...@apache.org>.
On 04/12/2012 Rob Weir wrote:
> On Dec 4, 2012, at 1:46 PM, Ariel Constenla-Haile wrote:
>> having all language packs built, not advertising them on our website
>> (that said, note that the dev. snapshots hosted on people.apache.org are
>> advertised on the main download page ;) ). And the goal is to point them
>> to user when they ask, or list them on the porting page, or using them
>> for ongoing translation efforts, etc.
This is a very good idea. Actually, I probably proposed it myself on
ooo-l10n a few months ago... But I really think that this can be an
extremely useful resource for prospective translators, and for the image
of the project in general.
> If we want something to be downloaded and used by the public then we
> should release it, period. We should not be looking for clever ways
> to avoid the important release steps of verifying IP, producing a
> source package and voting on it. This is what it means to be an
> Apache project.
We have plenty of ways to differentiate these from the packages we make
available from our download page: we could make a (monster-sized)
"multilingual build" instead of individual langpacks; we can rename the
product and make an "OOO-DEV" build; we can provide an "archive" build
(i.e., zipfiles with no installation).
I see the workflow this way:
- A user opens pl.openoffice.org and finds that Polish is not available
- A warning on that page takes him to a "Your help is needed" page
- This page provides information on how to help with translations in
general, plus a link to the "experimental build" above where the user
can see the current level of support for Polish
- Yes, someone might download the build and be OK with it, but we will
possibly gain translation volunteers, and they will be more motivated by
seeing in practice what "95% translated" means. And, of course, this
build will be very helpful for them when translating, so that they can
use it to see existing terminology and put untranslated strings in context.
The download page other.html would contain something like "If you don't
see your language here, help us to get it released!" and link to the
"Your help is needed" page above.
An important clarification: these sources have already been voted upon.
I can build the 3.4.1 sources from August with "--with lang=pl" and get
OpenOffice in Polish (well, 95% Polish and 5% English). So this is just
a build of OpenOffice 3.4.1 from the verified, voted and released sources.
Regards,
Andrea.
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ra...@gmail.com>.
On Dec 4, 2012, at 1:46 PM, Ariel Constenla-Haile <ar...@apache.org> wrote:
> On Tue, Dec 04, 2012 at 01:04:28PM -0500, Rob Weir wrote:
>> On Tue, Dec 4, 2012 at 12:27 PM, Ariel Constenla-Haile
>> <ar...@apache.org> wrote:
>>> On Tue, Dec 04, 2012 at 01:39:59PM +0100, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> based on some earlier discussion I think we have reached more common
>>>> consensus that we 1. want release further languages for AOO 3.4 1 and 2.
>>>> how we can do that.
>>>>
>>>> To make it more concrete I have created a new wiki page [1] where I
>>>> would like to document the release process, the proposed release
>>>> schedule, how the new translation will be integrated etc.
>>>>
>>>> The page is not yet complete and we can add further information on
>>>> demand. Please help me to document the issues, references to
>>>> dictionaries etc.
>>>>
>>>> I propose to extend the deadline a little bit to reflect the holidays
>>>> and the new year's day.
>>>>
>>>> Proposed release schedule:
>>>> - translation deadline, January 4th, 2013.
>>>> All new translation have to be available as attachment to a new related
>>>> issue for each language.
>>>> - availability of 1. developer snapshots, January 11th, 2013
>>>> - potential 2. developer snapshots, January 25th, 2013
>>>> - GA, January 31th, 2013
>>>>
>>>> Any opinions, concerns or feedback? Follow up discussion should take
>>>> place on the dev list only (the list where decisions are made).
>>>
>>> It may be a good idea to build all languages, or at least those with 80%
>>> of the UI translated, but release only those with 100%; we could leave
>>> the rest in people.apache.org as unofficial builds (at least langpacks),
>>> and point people to them instead of you-know-what http://s.apache.org/yY
>>
>> We can't do that. We either release or we don't release a language.
>> If we're not releasing it then we should not be pointing users to it
>> on people.apache.org. This is an issue both from Apache release
>> policy and Infra policy (bandwidth issues).
>
> Change people.apache.org for apache-extras or any other place. The idea
> is having all language packs built, not advertising them on our website
> (that said, note that the dev. snapshots hosted on people.apache.org are
> advertised on the main download page ;) ). And the goal is to point them
> to user when they ask, or list them on the porting page, or using them
> for ongoing translation efforts, etc.
>
If we want something to be downloaded and used by the public then we
should release it, period. We should not be looking for clever ways
to avoid the important release steps of verifying IP, producing a
source package and voting on it. This is what it means to be an
Apache project.
>
>> However, we could talk about actually releasing 80% complete
>> languages, maybe marking them "beta" or "provisional" or something
>> else. If we vote to release them then we can distribute via the
>> normal ways.
>
> Changing the package name might complicate the download logic.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Dec 04, 2012 at 01:04:28PM -0500, Rob Weir wrote:
> On Tue, Dec 4, 2012 at 12:27 PM, Ariel Constenla-Haile
> <ar...@apache.org> wrote:
> > On Tue, Dec 04, 2012 at 01:39:59PM +0100, Jürgen Schmidt wrote:
> >> Hi,
> >>
> >> based on some earlier discussion I think we have reached more common
> >> consensus that we 1. want release further languages for AOO 3.4 1 and 2.
> >> how we can do that.
> >>
> >> To make it more concrete I have created a new wiki page [1] where I
> >> would like to document the release process, the proposed release
> >> schedule, how the new translation will be integrated etc.
> >>
> >> The page is not yet complete and we can add further information on
> >> demand. Please help me to document the issues, references to
> >> dictionaries etc.
> >>
> >> I propose to extend the deadline a little bit to reflect the holidays
> >> and the new year's day.
> >>
> >> Proposed release schedule:
> >> - translation deadline, January 4th, 2013.
> >> All new translation have to be available as attachment to a new related
> >> issue for each language.
> >> - availability of 1. developer snapshots, January 11th, 2013
> >> - potential 2. developer snapshots, January 25th, 2013
> >> - GA, January 31th, 2013
> >>
> >> Any opinions, concerns or feedback? Follow up discussion should take
> >> place on the dev list only (the list where decisions are made).
> >
> > It may be a good idea to build all languages, or at least those with 80%
> > of the UI translated, but release only those with 100%; we could leave
> > the rest in people.apache.org as unofficial builds (at least langpacks),
> > and point people to them instead of you-know-what http://s.apache.org/yY
> >
>
> We can't do that. We either release or we don't release a language.
> If we're not releasing it then we should not be pointing users to it
> on people.apache.org. This is an issue both from Apache release
> policy and Infra policy (bandwidth issues).
Change people.apache.org for apache-extras or any other place. The idea
is having all language packs built, not advertising them on our website
(that said, note that the dev. snapshots hosted on people.apache.org are
advertised on the main download page ;) ). And the goal is to point them
to user when they ask, or list them on the porting page, or using them
for ongoing translation efforts, etc.
> However, we could talk about actually releasing 80% complete
> languages, maybe marking them "beta" or "provisional" or something
> else. If we vote to release them then we can distribute via the
> normal ways.
Changing the package name might complicate the download logic.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Dec 4, 2012 at 10:04 AM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Dec 4, 2012 at 12:27 PM, Ariel Constenla-Haile
> <ar...@apache.org> wrote:
>> On Tue, Dec 04, 2012 at 01:39:59PM +0100, Jürgen Schmidt wrote:
>>> Hi,
>>>
>>> based on some earlier discussion I think we have reached more common
>>> consensus that we 1. want release further languages for AOO 3.4 1 and 2.
>>> how we can do that.
>>>
>>> To make it more concrete I have created a new wiki page [1] where I
This looks good, and it looks like we need an issue filed for Danish...
>>> would like to document the release process, the proposed release
>>> schedule, how the new translation will be integrated etc.
>>>
>>> The page is not yet complete and we can add further information on
>>> demand. Please help me to document the issues, references to
>>> dictionaries etc.
>>>
>>> I propose to extend the deadline a little bit to reflect the holidays
>>> and the new year's day.
>>>
>>> Proposed release schedule:
>>> - translation deadline, January 4th, 2013.
>>> All new translation have to be available as attachment to a new related
>>> issue for each language.
>>> - availability of 1. developer snapshots, January 11th, 2013
>>> - potential 2. developer snapshots, January 25th, 2013
>>> - GA, January 31th, 2013
>>>
>>> Any opinions, concerns or feedback? Follow up discussion should take
>>> place on the dev list only (the list where decisions are made).
>>
>> It may be a good idea to build all languages, or at least those with 80%
>> of the UI translated, but release only those with 100%; we could leave
>> the rest in people.apache.org as unofficial builds (at least langpacks),
>> and point people to them instead of you-know-what http://s.apache.org/yY
>>
>
> We can't do that. We either release or we don't release a language.
> If we're not releasing it then we should not be pointing users to it
> on people.apache.org. This is an issue both from Apache release
> policy and Infra policy (bandwidth issues).
>
> However, we could talk about actually releasing 80% complete
> languages, maybe marking them "beta" or "provisional" or something
> else.
Well even if "provisional", some of these releases might be pretty
unfriendly for the end user. On the other hand, we might encourage
some involvement with completing these translations.
> If we vote to release them then we can distribute via the
> normal ways.
>
> Of course, if a translation is 80% AND we have volunteers working to
> complete it, then it makes sense to build milestone builds with those
> languages, to facilitate the translation and QA work of those
> languages.
>
> -Rob
>
>
>>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
--
----------------------------------------------------------------------------------------
MzK
“How wrong is it for a woman to expect the man to build the world
she wants, rather than to create it herself?”
-- Anais Nin
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Rob Weir <ro...@apache.org>.
On Tue, Dec 4, 2012 at 12:27 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> On Tue, Dec 04, 2012 at 01:39:59PM +0100, Jürgen Schmidt wrote:
>> Hi,
>>
>> based on some earlier discussion I think we have reached more common
>> consensus that we 1. want release further languages for AOO 3.4 1 and 2.
>> how we can do that.
>>
>> To make it more concrete I have created a new wiki page [1] where I
>> would like to document the release process, the proposed release
>> schedule, how the new translation will be integrated etc.
>>
>> The page is not yet complete and we can add further information on
>> demand. Please help me to document the issues, references to
>> dictionaries etc.
>>
>> I propose to extend the deadline a little bit to reflect the holidays
>> and the new year's day.
>>
>> Proposed release schedule:
>> - translation deadline, January 4th, 2013.
>> All new translation have to be available as attachment to a new related
>> issue for each language.
>> - availability of 1. developer snapshots, January 11th, 2013
>> - potential 2. developer snapshots, January 25th, 2013
>> - GA, January 31th, 2013
>>
>> Any opinions, concerns or feedback? Follow up discussion should take
>> place on the dev list only (the list where decisions are made).
>
> It may be a good idea to build all languages, or at least those with 80%
> of the UI translated, but release only those with 100%; we could leave
> the rest in people.apache.org as unofficial builds (at least langpacks),
> and point people to them instead of you-know-what http://s.apache.org/yY
>
We can't do that. We either release or we don't release a language.
If we're not releasing it then we should not be pointing users to it
on people.apache.org. This is an issue both from Apache release
policy and Infra policy (bandwidth issues).
However, we could talk about actually releasing 80% complete
languages, maybe marking them "beta" or "provisional" or something
else. If we vote to release them then we can distribute via the
normal ways.
Of course, if a translation is 80% AND we have volunteers working to
complete it, then it makes sense to build milestone builds with those
languages, to facilitate the translation and QA work of those
languages.
-Rob
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE]: new languages for AOO 3.4.1
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Dec 04, 2012 at 01:39:59PM +0100, Jürgen Schmidt wrote:
> Hi,
>
> based on some earlier discussion I think we have reached more common
> consensus that we 1. want release further languages for AOO 3.4 1 and 2.
> how we can do that.
>
> To make it more concrete I have created a new wiki page [1] where I
> would like to document the release process, the proposed release
> schedule, how the new translation will be integrated etc.
>
> The page is not yet complete and we can add further information on
> demand. Please help me to document the issues, references to
> dictionaries etc.
>
> I propose to extend the deadline a little bit to reflect the holidays
> and the new year's day.
>
> Proposed release schedule:
> - translation deadline, January 4th, 2013.
> All new translation have to be available as attachment to a new related
> issue for each language.
> - availability of 1. developer snapshots, January 11th, 2013
> - potential 2. developer snapshots, January 25th, 2013
> - GA, January 31th, 2013
>
> Any opinions, concerns or feedback? Follow up discussion should take
> place on the dev list only (the list where decisions are made).
It may be a good idea to build all languages, or at least those with 80%
of the UI translated, but release only those with 100%; we could leave
the rest in people.apache.org as unofficial builds (at least langpacks),
and point people to them instead of you-know-what http://s.apache.org/yY
Regards
--
Ariel Constenla-Haile
La Plata, Argentina