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

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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>


-- 

<http://www.oracle.com/>
Dipl.-Ing. Frank Grzesiak-Mau | Translation, IssueTracking, Web-tools
Phone: +49 40 23646894
OracleOracle 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

<http://www.oracle.com/commitment>

	

Oracle is committed to developing practices and products that help 
protect the environment