On 7 August 2013 16:44, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> On 8/7/13 2:09 PM, janI wrote: > > On 7 August 2013 14:04, sebb <seb...@gmail.com> wrote: > > > >> 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. > >> > > > > 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. You might prefer single projects, but e.g. a refresh_stat command should be used across all projects. 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. 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. 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-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 > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
