On 7 August 2013 14:04, sebb <[email protected]> wrote: > On 7 August 2013 12:55, Jürgen Schmidt <[email protected]> wrote: > > On 8/7/13 1:51 PM, janI wrote: > >> On 7 August 2013 13:07, Jürgen Schmidt <[email protected]> wrote: > >> > >>> On 8/7/13 11:47 AM, janI wrote: > >>>> On 7 August 2013 11:28, Jürgen Schmidt <[email protected]> wrote: > >>>> > >>>>> On 8/6/13 6:42 PM, janI wrote: > >>>>>> On 6 August 2013 17:15, Andrea Pescetti <[email protected]> > 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 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< > >>>>> [email protected]> > >>>>>>> For additional commands, e-mail: [email protected] > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
