openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Proposal -- AOO 4.0.1 Release
Date Wed, 07 Aug 2013 12:09:39 GMT
On 7 August 2013 14:04, sebb <sebbaz@gmail.com> wrote:

> On 7 August 2013 12:55, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
> > On 8/7/13 1:51 PM, janI wrote:
> >> On 7 August 2013 13:07, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
> >>
> >>> On 8/7/13 11:47 AM, janI wrote:
> >>>> On 7 August 2013 11:28, Jürgen Schmidt <jogischmidt@gmail.com>
wrote:
> >>>>
> >>>>> On 8/6/13 6:42 PM, janI wrote:
> >>>>>> On 6 August 2013 17:15, Andrea Pescetti <pescetti@apache.org>
> wrote:
> >>>>>>
> >>>>>>> Jürgen Schmidt wrote:
> >>>>>>>
> >>>>>>>> On 8/6/13 3:05 PM, Andrea Pescetti wrote:
> >>>>>>>>
> >>>>>>>>> It is important that we don't fall in the "release
and forget"
> trap,
> >>>>>>>>> i.e., "this bug was already known when 4.0 was released,
so it
> >>> doesn't
> >>>>>>>>> need to be evaluated again for 4.0.1". At least,
we should
> >>> re-evaluate
> >>>>>>>>> the old proposed blockers: some of them might have
become more
> >>>>> relevant.
> >>>>>>>>>
> >>>>>>>> in theory and with an idealistic view I would agree
but for
> practical
> >>>>>>>> reason I don't. You should not forget that issues have
to be
> fixed as
> >>>>>>>> well.
> >>>>>>>> We should really be careful here and should focus on
the most
> serious
> >>>>>>>> issues only. From my point of view many proposed showstoppers
for
> 4.0
> >>>>>>>> were no showstopper and why should we prioritize them
now.
> >>>>>>>>
> >>>>>>>
> >>>>>>> We shouldn't prioritize them, just look at them again. My
> suggestion
> >>> was
> >>>>>>> to have regressions and old nominated blockers as PROPOSED
blockers
> >>>>>>> (status: ?), not as blockers (status: +). Some will have
to be
> >>> rejected
> >>>>>>> again, obviously; but it is very bad, as a user and a community
> >>> member,
> >>>>> to
> >>>>>>> get an answer like my (made up) example above. Of course,
anybody
> who
> >>> is
> >>>>>>> concerned can propose an issue as a blocker, but a quick
review
> makes
> >>>>> sense
> >>>>>>> in my opinion.
> >>>>>>>
> >>>>>>>
> >>>>>>>  we have volunteers who are ready to
> >>>>>>>>> work and Pootle is not ready yet for their language,
or it only
> >>> offers
> >>>>>>>>> 3.4.1. See http://markmail.org/message/**4oxacrviktdbmbcv<
> >>>>> http://markmail.org/message/4oxacrviktdbmbcv>for more.
> >>>>>>>>>
> >>>>>>>> where are the issues? Where are the volunteers to work
on this?
> >>> Nobody
> >>>>>>>> should plan with other peoples time and willingness
> >>>>>>>>
> >>>>>>>
> >>>>>>> One issue: https://issues.apache.org/ooo/**show_bug.cgi?id=122910<
> >>>>> https://issues.apache.org/ooo/show_bug.cgi?id=122910>
> >>>>>>>
> >>>>>>> As for the volunteers, I understand that the Pootle update
is a
> lot of
> >>>>>>> work, as I wrote. Fact is, this lot of work is instrumental
in
> >>>>> attracting
> >>>>>>> volunteers successfully and will remain the same amount
of work
> >>> whether
> >>>>>>> done now or after 4.0.1. And doing it now (or soon) is a
nice
> >>>>> opportunity
> >>>>>>> for the project for a combination of reasons: OpenOffice
4.0 had
> great
> >>>>>>> exposure, volunteers want to translate it into their language,
> Summer
> >>> is
> >>>>>>> the best period for people to contribute in their spare
time,
> telling
> >>>>>>> someone that his efforts will be turned into an official
release
> next
> >>>>> month
> >>>>>>> is very motivating... But indeed so far you are the only
one who
> >>>>> actually
> >>>>>>> did this Pootle administration work.
> >>>>>>
> >>>>>>
> >>>>>> I can give a hand, with this work, but reading through the mails
it
> >>> seems
> >>>>>> we have quite a few open issues (mainly raised by jsc):
> >>>>>> - Should we make 4.01 in pootle or as suggested continue working
on
> >>> 4.0 ?
> >>>>>
> >>>>> if we create a new project I would use 4.0.1
> >>>>>
> >>>>> I see you have created new project names and used again a new naming
> >>>>> scheme, why?
> >>>>>
> >>>>> old aoo40
> >>>>>
> >>>>> new a00401
> >>>>>
> >>>>> This makes it not easier to get an overview
> >>>>>
> >>>> I know, but this was just an experiment to test if I could copy the
db
> >>>> easily. That did not work, so its the old way, as described below.
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> - Do we want to add languages where we have no translation teams
?
> >>>>>
> >>>>> I would only add languages where we have an active translating
> >>>>> community. We should save all other languages in a secure place
and
> add
> >>>>> them on demand or we create a further project where we add all
> inactive
> >>>>> languages and keep them more or less up-to-date by merging to the
> latest
> >>>>> templates
> >>>>>
> >>>>
> >>>> so you dont agree with andrea, that argues (correctly) its a
> motivation
> >>>> factor to see that part of the language is already translated.
> >>>>
> >>>> also keep in mind, that genLang hopefully comes soon, then we need to
> >>>> convert the sdf files anyhow, not to loose the information.
> >>>
> >>> as I mentioned store them in a secure place or an additional project
> but
> >>> away from the active ones. Simply reduced work and the motivation of
> >>> people who actually do the work is important as well ;-)
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>> - How do we merge languages changed in pootle and sdf ?
> >>>>>
> >>>>> We should not merge sdf files back. We work with po files and use
> Pootle
> >>>>> to manage them and get an overview where we are. Offline translation
> >>>>> will be merged on Pootle first.
> >>>>>
> >>>> we need to, first of all we have sdf files that have not been
> converted
> >>> to
> >>>> po, second we have 3.4.1 po files that need to be updated from sdf to
> 4.0
> >>>> level.
> >>>
> >>> sure we have to do it ones but I talked more about the handling after
> >>> this initial step
> >>>
> >>>>
> >>>>>
> >>>>> And with your new translation tools sdf files become obsolete
> >>> completely.
> >>>>>
> >>>>
> >>>> yes, but thats just so much more reason to get all sdf files
> synchronized
> >>>> now.
> >>>
> >>> I think I said this already. 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 will simply copy aoo40 to aoo4.0.1, no merge or anything else.
> >>
> >> I am currently running refresh_stat, and looking at how long it takes,
> it
> >> must have been quite a while since it last ran. After that comes
> >> sync_stores in aoo400.
> >>
> >> then copy aoo400 dir to aoo4.0.1 and update_stores.
> >
> > let us use aoo401 without dots for the physical name on disk and Apache
> > OpenOffice 4.0.1 as UI name
>
> Dropping the dots can potentially create ambiguous names.
> Probably not a problem unless there are many versions available
> simultaneously, but something to be aware of.
>

correct, and a fast test, showed that we will have problems if project name
!= disk name.

No global pootle commands will work (refresh_stat, sync_stores), that has
to be done for each project. And if you forget it and use a global command,
pootle creates the . filled dir for you.

Due to the outcome of my test, I will stick to project name == disk name

rgds
jan I.


>
> >>
> >> that runs in a window on my pc, so it is not really extra work.
> >>
> >> Hope that also satisfies the requests from andrea.
> >>
> >> rgds
> >> jan I.
> >>
> >>
> >>>
> >>> Juergen
> >>>
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> @jsc, I have trunk on my linux, so I suggest the following procedure
> >>>>>> (provided you agree):
> >>>>>>
> >>>>>> 1) I convert all sdf files to po files (to be sure lets agree
> offlist
> >>> on
> >>>>>> the actual cmds and parm to use)
> >>>>>
> >>>>> I am fine with this, ping me for details
> >>>>>
> >>>> will do.
> >>>>
> >>>>
> >>>>>
> >>>>> But we should merge the po files with the latest new template files
> for
> >>>>> AOO 4.0 to keep everything in sync.
> >>>>>
> >>>>> I don't know why but I noticed sometimes some problems here and
I
> have
> >>>>> to do it twice to get the same and correct word count.
> >>>>>
> >>>>> By the way the Danish pootle-terminology.po file confused me every
> time
> >>>>> and needs special handling when merged etc.
> >>>>>
> >>>> hmmm dont understand why, its a normal po file, just created by
> pootle.
> >>>> When you upload to the pootle db it is special handled.
> >>>>
> >>>> This is actually something all languages should have.
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> 2) upload the PO files to a temp dir on translate-vm2.a.o
> >>>>>> 3) sync db with po dir on translate-vm2.a.o
> >>>>>> 4) create project 4.01 with content of 4.0
> >>>>>> 5) compare if Pootle files contain newer info then sdf-PO files
> (this
> >>>>> will
> >>>>>> be the difficult part)
> >>>>>
> >>>>> mmh, I am not sure if I understand what you want to do here. Pootle
> is
> >>>>> our source and we convert old sdf files to po, merge with the latest
> >>>>> templates and update Pootle. Languages that are on the 4.0 project
> >>>>> already have to be not merged. Pootle is the source here.
> >>>>>
> >>>>
> >>>> as a side remark, svn is our source not pootle. Pootle is just our
> work
> >>>> area.
> >>>>
> >>>> I assume step 2,3,4) are simple an clear. so now I have PO files from
> >>>> Pootle and PO files from sdf. We have languages (I saw that in my last
> >>>> test), where the following is true:
> >>>> - sdf generated PO files contains translated entries not in Pootle db
> >>>> - Pootle db contain translated entries not in the sdf file
> >>>>
> >>>> hence the  merge procedure.
> >>>>
> >>>> rgds
> >>>> jan I.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>> 6) create new languages
> >>>>>> 7) overwrite PO-dir with sdf-PO
> >>>>>
> >>>>> use the updated and merged po files, merged against the latest
> template
> >>>>> files
> >>>>>
> >>>>>> 8) sync PO dir with pootle (only for lang. with differences)
> >>>>>>
> >>>>>> If we agree, I can do it very fast (within a day).
> >>>>>>
> >>>>>
> >>>>> I would as mentioned earlier only support langs where we see an
> active
> >>>>> community. Move all other langs in a separate project to reduce
the
> work
> >>>>> long term. And we should remove them from the source temporary as
> long
> >>>>> as they are not supported.
> >>>>>
> >>>>> Juergen
> >>>>>
> >>>>>> rgds
> >>>>>> jan I.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Regards,
> >>>>>>>   Andrea.
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> ------------------------------**------------------------------**---------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> >>>>> 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
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
>
> ---------------------------------------------------------------------
> 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