Alexandro Colorado
Wed, 17 Mar 2010 16:07:33 -0700
The request is to partially fund the buildbox, so given the response, my guess is that most people are ok with this. Please let's try to approve the budget so we can move on. The platform would be on linux and will improve the spanish locale.
Regards On 3/17/10, Ivo Hinkelmann <ivo.hinkelm...@sun.com> wrote: > Hi Santiago, > > we are currently moving to the latest version of Pootle. This new > version will also run on a new machine. As soon as this is up and > running well and we moved all translation to this new machine we would > like update the pootle source strings more frequently. Every milestone > or lets say at least once every month. I am not yet sure how to deal > with the different codelines, e.g. OOO320 vs. DEV300 . > > At the moment we don't have the resources here to build instsets / > langpacks for every language on the development codeline ( DEV300 ). > > Cheers, > Ivo > > Santiago Bosio wrote: >> Martin Hollmichel escribió: > >>> Hi Santiago, >>> >>> I think it's an good plan to verify localization (and terminology) as >>> a early as possible.Are there any technical hurdles to import >>> incremental localization updates from pootle and do frequent builds. >>> Can this also easily be done for more languages than Spanish ? What >>> would be your preferred platform for doing this ? >>> >>> Martin >> Hi Martin: >> >> Perhaps somebody from the l10n project can give better technical >> background about the workflow on translation and why the process doesn't >> admit changes after the localisation CWS has been integrated. >> >> We have been working with Pootle, open language tools, and gsicheck and, >> personally, I consider that string translation changes are of the safest >> changes that can be introduced (provided that they are checked and >> sanitized) without breaking builds or causing problems. And even when we >> considered some translation errors as show-stoppers, their corrections >> weren't accepted in RC stage, and were delayed to next bugfix release. >> >> As I said, we have been doing our own builds, patching the translations >> with the latest snapshot from Pootle, converted to OOo SDF format using >> po2oo, and gsichecking the resulting file. All of it can be done >> automatically, but I see two problems to solve for the "as early as >> possible" scenario: >> >> 1. Pootle updates are done only after UI and string freeze. Then these >> new or modified strings are available for a few weeks to be translated, >> before localisation CWS integration, and after that, usually a two week >> period to introduce changes before first RC. Ideally, new or modified >> strings should be inmediately available on Pootle to alleviate the >> translation burden when too many strings were introduced/modified. Also, >> I think translation updates must be accepted in-between RC's when NL >> project leaders ask to do so, and next RC built with the last snapshot >> from Pootle. >> >> 2. Weekly devel builds should be done with the complete set of language >> packs, and not only a few of them as it is done currently (I think they >> are FR, DE, IT, JA, pt-BR, etc.) as it will give us the opportunity to >> check our advance (provided that we have early the strings to translate >> on Pootle as I said before). >> >> Regardless of that, on our community we have a specific problem with our >> translation: it has a poor overall quality, and this review process I >> described on my previous e-mail must be carried out outside the current >> translations on Pootle, because if we did otherwise, we can get as a >> result a more confusing translation on the next upcoming releases. So, >> we still need a local box to do our own builds to test the revision >> process until it gets to an acceptable degree of quality to merge the >> changes back to Pootle. >> >> Best regards, >> >> Santiago >> >> PD: I'm cross-posting this message to l10n dev list. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.org >> For additional commands, e-mail: dev-h...@openoffice.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org > For additional commands, e-mail: dev-h...@l10n.openoffice.org > > -- Alexandro Colorado OpenOffice.org Español "Support this 31st March - Document Freedom Day " http://www.documentfreedom.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org