On 8/7/13 2:04 PM, janI wrote: > 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.
but you used a00401 instead of aoo401 ;-) That is at least what I see on the disk. And now I see also aoo4.0.1 and aoo4.0.1help The 4.x project used exaxctly aoo40/aoo40help on disk and "Apache OpenOffice 4.x"/"Apache OpenOffice 4.x Help" in the Pootle UI 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
