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 Thu, 08 Aug 2013 08:15:43 GMT
On 8 August 2013 08:06, Jürgen Schmidt <jogischmidt@gmail.com> wrote:

> On 8/7/13 8:44 PM, janI wrote:
> > 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.
>
> well I noticed that I have new rights and can't create projects anymore :-(
>

you actually received a mail about a month ago about the setup changes,
when andrea joined the administrators.


>
> We should not mix things here I am talking about the name on the disk
> that is probably the same as the project name (I can't check anymore)
> and the visible display name.
>
> If we use the short name aoo401 or aoo410 or aoo500 the global commands
> will always work. We don't need the dots here in the name, please keep
> it simple it's for our internal use only. The display name should of
> course show a more descriptive name.
>
fine we are back to my original proposal, I just tried to implement your
wish (see earlier mail in this thread).


>
> Yes we share the server but we use a very unique naming scheme for our
> project.
>
The naming is actually quite normal (apart from help, which should really
have been aoohelp401).



>
>
> >
> > You might prefer single projects, but e.g. a refresh_stat command should
> be
> > used across all projects.
>
> that will work
>
>
> >
> > 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.
>
> It seems that we had a misunderstanding here, the internal project name
> is indeed always the name if the disk directory
>
> But I still don't understand why you have started a new naming scheme. I
> tried to establish a new simple one starting with AOO 4.0 and now
> instead of using the same you started a new one with dots. I simply
> don't understand.
>

Well read your own mails (earlier in this thread) you wrote that you
preferred aoo4.0.1

and maybe take a look what the status of translate actually is :-)

rgds
jan I.



>
> >
> > 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.
> >
>
> we should definitely create a cron job for this
>
> Juergen
>
>
> > 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
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> 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