openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@gmail.com>
Subject Re: Proposal -- AOO 4.0.1 Release
Date Thu, 08 Aug 2013 06:06:42 GMT
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 :-(

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.

Yes we share the server but we use a very unique naming scheme for our
project.


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


> 
> 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
View raw message