On 7 August 2013 13: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 > I have already created the project as you asked "if we create a new project I would use 4.0.1", and I am not sure I can use a different name on the disk, but I can try. It would at least complicate things more because you would have to use commandline options to identify the difference. Actually that was why I preferred aoo401. 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-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 > >
