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 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
