openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Pootle setup for 4.0.1 (Re: Proposal -- AOO 4.0.1 Release)
Date Thu, 08 Aug 2013 14:33:21 GMT
On 8 August 2013 15:28, Jürgen Schmidt <jogischmidt@gmail.com> wrote:

> On 8/8/13 3:06 PM, Andrea Pescetti wrote:
> > On 07/08/2013 janI wrote:
> >> On 7 August 2013 13:07, Jürgen Schmidt wrote:
> >>> We have to convert them all in po, merge
> >>> against the latest templates from 4.0 and safe them in a secure
> >>> place/project and use new languages on demand
> >> No problem, I would have preferred another way, but this is less work
> >> now.
> >
> > I'm renaming this subthread, since we all agree on the 4.0.1 proposal in
> > itself and discussions are only on the Pootle update now.
> >
> > I see in Pootle that the project names, after the discussion here, now
> > follow the same pattern of 4.0.0: "aoo401" and "aoo401help": perfect.
> >
> > The point where I and Juergen disagree is how many languages should be
> > available in Pootle.
> >
> > My deepest concern is that we don't waste the translators' time and that
> > we are prepared to receive help immediately. So, for me, now is the time
> > for importing everything from SDF to Pootle: we still have at least
> > three languages (sr, sh, bg) where volunteers have been waiting for more
> > than one week for us to put 4.0.0 in Pootle.
> >
> > Juergen, how can we guarantee that this is not the bottleneck if we
> > don't import everything now? As for creating Pootle accounts, I usually
> > create them within 24 hours, which is fine. But creating a Pootle
> > project (a new language) looks more complex and more critical.
>
> by simply having a few more people having the necessary rights to access
> the machine and doing the work directly.
>

These people would also need to understand the pootle setup, since root
access is needed. I will not recommend have extra root people on the vm,
but if really needed we could change ownership of the po files so the
vm-team can do the po commands.


> Having all languages there requires even more maintenance work over time
> that I am not willing to spend if there is no active community
>

You see something that I overlook, please enlighten me.

Apart from the initial work (which have to be done at some point anyhow), I
see our running maintenance as:
- Maintain mysql, httpd and pootle (that is done by me alone today, and I
dont need extra help)
- Restart pootle in case of problems (that is done by vm-team, in total 5
people, that should be enough)
- Run "pootle refresh_stat" regulary (done by me, and with my current
experience I will put it in crontab)
- Run  "pootle sync" to update the po files for backup (currently only done
by you, but I will be happy to put that in crontab as well, and btw 1 cmd,
not 1 pr language).

When we want to build for a release, there are a couple of extra issues:
- Convert po files back to sdf (currently done by you, but that would only
affect the languages we actually build, so no difference from today).

The only real extra work is when there are new strings:
- Convert sdf files with templates to po files for each language.

This is real extra work, but I have proposed to do it this time, and I hope
to have genLang ready for 4.1, so we can skip the conversion.

What extra work am I missing ?



>
> I stopped to add languages more or less when we started the 4.0.1
> discussion ...
>
> You will notice that initial 4.x projects use of course 4.x and not 4.0.
> My understanding is that only the sdf files in svn count and Pootle is
> just a tool. And in future the po files in svn counts instead of. I
> don't think they have to be in sync. But anyway if people want to have
> the overhead I am fine as long as I don't have to do the work.
>
I agree that svn is the source, and pootle is only a tool, but in the
future the po directory will be direcly couple to svn (whether we allow
pootle users to commit is a different discussion).

In the future (genLang and already tested) the idea is:
- have the po directory made as a checkout from svn (main/languages)
- after a pootle sync command, manually commit to svn (or if  agreed upon,
let the pootle user do that).

so in the (hopefully) near future, only real maintenance needs to access
the server.


>
> Juergen
>
> >
> > As for the rest, see http://markmail.org/message/4oxacrviktdbmbcv but
> > some important remarks are:
> >
> > 1) Languages that have 3.4.1 but not 4.0.0 in Pootle: preserve their
> > work in the "aoo401" project (I don't know what this entails, but I
> > assume that Jan's remarks about merging with the 4.0 templates apply
> here)
>
that was my intention, of course first after we agree on it. The offer
still stands, but I need to agree on the commands with jsc.



> >
> > 2) Languages that have 4.0.0 in Pootle: preserve their work in the
> > "aoo401" project (so, Jan, I believe that cloning aoo400->aoo401 is OK
> > for this).
>

correct

> >
> > 3) Make "aoo401" the only active/writable/actionable/visible project,
> > whatever options Pootle offers: volunteers should not be able to work on
> > 3.4.1 or 4.0.0 on Pootle any longer, it would be wasted time.
>

This is a bit difficult, pootle does not offer a readonly possibility.

I am all for removing the old projects (that will save both jsc and me
time), but I understood on jsc that he wanted to keep them. We loose
nothing be removing the old projects, since the source is in svn (sdf
files).



> >
> > (Obviously, the same holds for "aoo401help")
>
claro :-)

rgds
jan I

> >
> > Regards,
> >   Andrea.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message