On 8/7/13 8:44 PM, janI wrote: > 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.
well I noticed that I have new rights and can't create projects anymore :-( We should not mix things here I am talking about the name on the disk that is probably the same as the project name (I can't check anymore) and the visible display name. If we use the short name aoo401 or aoo410 or aoo500 the global commands will always work. We don't need the dots here in the name, please keep it simple it's for our internal use only. The display name should of course show a more descriptive name. Yes we share the server but we use a very unique naming scheme for our project. > > You might prefer single projects, but e.g. a refresh_stat command should be > used across all projects. that will work > > 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. It seems that we had a misunderstanding here, the internal project name is indeed always the name if the disk directory But I still don't understand why you have started a new naming scheme. I tried to establish a new simple one starting with AOO 4.0 and now instead of using the same you started a new one with dots. I simply don't understand. > > 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. > we should definitely create a cron job for this Juergen > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
