[l10n-dev] Re: [l10n-tools] The localization process will be changed into a continuous process soon

[Frank Mau]

Hi Dwayne, yes, we will try to use sdf-errors (coming out of gsicheck or future-tooling) to identify strings directly in Pootle so translation-problems/errors will directly visible for the translator. Currently we update Pootle for each milestone so continuous translation plus l10n-dev-builds (cont. l10n-builds) are possible for the latest milestone. We believe that's a very good way to have a 'real' cont. l10n process in the future. Cheers, Frank Am 10.12.2010 08:22, schrieb Dwayne Bailey: On 09/12/2010 14:51, Ivo Hinkelmann wrote: I am happy to announce that soon the localization process will be changed into a continuous process which will allow to provide l10n turnarounds cycles at every milestone. This process was presented at the OooConf In Budapest: http://www.ooocon.org/index.php/ooocon/2010/paper/view/207 and is the outcome of Gregor, Rafaella and myself working on the so called "continuous l10n" project. This is great news :) Here below the major steps of this workflow: *it creates a cws named l10n<workstamp><milestone> , e.g. l10ndev300m94 *it downloads all l10n from pootle *it downloads  all sdf found on ftp://qa-upload.services.openoffice.org/l10n/upload/ (no more sdf delivery via Issue. Translated sdf files can be uploaded to this ftp) *it gsichecks and merges the translated sdf files. Precondition is that language is known and is set up in the resource system. Are you applying any of the po2oo checks?  These catch a few critical errors that would ensure that broken translations are dropped, gsicheck passes and at least a local lang build is made. *it builds languagepacks for all languages that have been changed (even when only 1 string has been changed) + one en-US insetsets *it removes automatically languages from the build which cause a build error not covered by the gsicheck, this allowing the other languages to be built. *it uploads the *_err.sdf from gsicheck I wonder if its possible to use these *_err.sdf reports to report errors to Pootle users for fixing?  That way any translator could step through the GSI failure in Pootle and make corrections. *it uploads windows and linux32 languagepacks and the en-US insetsets to ftp://qa-upload.services.openoffice.org/l10n/download/ Please help us testing this new process! How? *Check the language packs created by this process *Non-Pootle users should upload translated sdf files to ftp://qa-upload.services.openoffice.org/l10n/upload For a later stage we are planning to * commit the l10n * integrate every cws We are working already on a technical solution that will not blow up the main repository. We will not integrate those cws till we solve this issue. Cheers, Ivo --------------------------------------------------------------------- To unsubscribe, e-mail: tools-unsubscr...@l10n.openoffice.org For additional commands, e-mail: tools-h...@l10n.openoffice.org -- Dipl.-Ing. Frank Grzesiak-Mau | Translation, IssueTracking, Web-tools Phone: +49 40 23646894 Oracle Oracle Open Office Operations ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment