On 8 August 2013 08:06, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> 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 :-( > you actually received a mail about a month ago about the setup changes, when andrea joined the administrators. > > 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. > fine we are back to my original proposal, I just tried to implement your wish (see earlier mail in this thread). > > Yes we share the server but we use a very unique naming scheme for our > project. > The naming is actually quite normal (apart from help, which should really have been aoohelp401). > > > > > > 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. > Well read your own mails (earlier in this thread) you wrote that you preferred aoo4.0.1 and maybe take a look what the status of translate actually is :-) rgds jan I. > > > > > 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 > >
