On 8/8/13 10:15 AM, janI wrote: > 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.
yes I remember and I forgot to answer in time, it's a limitation from my perspective and not useful > > >> >> 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). no, you misunderstood me. I meant 4.0.1 for the display name but it's of course my mistake to be not more explicit. And I gave examples of the disk names I saw old aoo40 aoo40help new a004.0.1 a00401 a00401help aoo4.0.1 aoo4.0.1help expected from my perspective aoo401 aoo401help > > >> >> 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). well I simply appended "help" to the main project. I haven't thought too much about this Juergen > > > >> >> >>> >>> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
