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 Wed, 07 Aug 2013 14:44:16 GMT
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

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