On 7 August 2013 12:55, Jürgen Schmidt <jogischm...@gmail.com> wrote: > On 8/7/13 1:51 PM, janI wrote: >> On 7 August 2013 13:07, Jürgen Schmidt <jogischm...@gmail.com> wrote: >> >>> On 8/7/13 11:47 AM, janI wrote: >>>> On 7 August 2013 11:28, Jürgen Schmidt <jogischm...@gmail.com> wrote: >>>> >>>>> On 8/6/13 6:42 PM, janI wrote: >>>>>> On 6 August 2013 17:15, Andrea Pescetti <pesce...@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. >> >> 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-unsubscr...@openoffice.apache.org> >>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>> >>>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
