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 18:44:53 GMT
On 7 August 2013 16:44, Jürgen Schmidt <jogischmidt@gmail.com> wrote:

> On 8/7/13 2:09 PM, janI wrote:
> > 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
>
> that sounds really like a bug and I would always prefer to run the
> commands on the projects you want explicitly and not global on all
>

You cannot really call it a bug, the project settings contain no field to
define  a directory.

You might prefer single projects, but e.g. a refresh_stat command should be
used across all projects.

personally I prefer to start the sync command on all projects, and leave
the terminal (go for coffee) while it runs. I also highly agree with sebb
that not using the same name leads to more confusion, we share this server
with all (potentially) asf projects.

for general info refresh_stat has been running for more than 5 hours now,
and is finally slowly comming to an end, then I will start the sync job.

rgds
jan I

Juergen
>
> >
> > 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
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> 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