incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: [POOTLE]: Proposed approach to bring the Pootle server into a well defined state
Date Mon, 19 Mar 2012 16:28:02 GMT
On 3/19/12 5:00 PM, eric b wrote:
>
> Le 19 mars 12 à 15:17, Jürgen Schmidt a écrit :
>
>> Hi,
>
>
> Hi,
>
>
>>
>> based on the analysis [1] of Andre and the feedback I got from
>> Raphael, Pavel, Claudio I would like to propose the following approach
>> to bring our AOO project on the Apache Pootle server into a well
>> defined state.
>> Status: Raphael had set up the current project based on the backup data.
>>
>> We have 2 projects, one for UI and one for Help. I think that is a
>> good schema that we should use in the future as well. For the future I
>> would propose a schema where we have a 2 projects. One for the last
>> stable version to allow translators to finish their translation work
>> for a stable release. And a second working project that we use for
>> continuous integration and ongoing translation work.
>>
>> Something like
>> aoo34 - Apache OpenOffice 3.4 UI
>> aoo34help - Apache OpenOffice 3.4 Help
>>
>> aoo40 - Apache OpenOffice 4.0 UI
>> aoo40 - Apache OpenOffice 4.0 Help
>>
>> Proposal
>> - update the existing Pootle server with a new set of templates [2]
>> based on the latest en-US.sdf [3] file that I have prepared on the
>> current sources.
>>
>> - sync the already available language against the new templates
>>
>> - if no problems comes up (worked locally for me) we can start with
>> the translation work o the pootle server.
>>
>> - integrate the new pt-BR po files on the Pootle server as well. As
>> well as all other potentially new available languages
>>
>> - ones we have a language completed, we will integrate it back in the
>> po/sdf files and integrate it our repository.
>>
>
>
> Is there a documentation explaining how to
>
> 1) turn .sdf into .pot, and
> 2) how .po files are turned into .sdf ?
>
> Even a script, or the right command lines would make me happy ;-) Thanks
> in advance !

well reading my email would have helped ;-) Especially the references 
and here the roundtrip section under [1]

Juergen

>
>
>
>> For technical details how to do each step you can visit the round trip
>> section under [1].
>>
>> We should also think about future improvements, see Andre comments
>> under [1]. There is huge room for improvements and we can think about
>> a continuous integration of the localizations. At least from the
>> pootle server into our repo ... But that is something for later
>>
>> Most important is that we get a well defined start state to begin ;-)
>>
>> Any opinions or further ideas?
>>
>
>
> For the future, I'd suggest, in every l10n/source/$a_locale, to split
> .sdf into stable and unstable part. Looks like sort of cws, but for
> localize.sdf files. The timing could be:
>
> - UI translation freeze : after QA, the localize.sdf will become stable,
> means keep it modified until next release.
> - All new strings, will be added in one new file, named
> localize-unstable.sdf (in every l10n/source/$a_locale), and we'll
> continue this way until the next UI translation freeze.
> - When all the strings in unstable will be considered as ok, let's merge
> its content in the stable part.
>
> btw : I wrote one crappy bash script creating new .sdf files from ascii
> files containing new constants, pathes and english-US strings. Just in
> case ...
>
>
> Back to the feature, the stable part, once verified ok, will keep its
> content until the next push. And so on. Could be done this way in Apache
> OpenOffice (untested .. needs to be verified) :
>
> Index: extras/l10n/source/makefile.mk
> ===================================================================
> --- extras/l10n/source/makefile.mk (revision 1214431)
> +++ extras/l10n/source/makefile.mk (working copy)
> @@ -38,8 +38,14 @@
> @echo "Nothing to do - en-US only build."
> .ELSE
>
> -all_sdfs:=$(shell cd $(PRJ)/source && ls -1 */localize.sdf)
>
> +.IF "$L10N_TEST" != ""
> +LOCALIZE_FILES= \
> + localize-unstable.sdf
> +.ENDIF
> +
> +all_sdfs:=$(shell cd $(PRJ)$/source && ls -1 *$/{localize.sdf
> ${LOCALIZE_FILES}})
> +
> .INCLUDE .IGNORE : $(COMMONMISC)/sdf/lock.mk
>
> .INCLUDE : target.mk
>
> As example, here is what I did for OOo4Kids and OOoLight (the idea of
> the localize-OOo.sdf was to contribute back the presenter screen or
> annotation mode strings into AOOo). As you can see, the idea is a bit
> different, but the principle counts here :
>
>
> .IF "$(OOo4Kids)"=="YES"
> application_name=-OOo4Kids
> .ELSE
> .IF "$(OOoLight)"=="YES"
> application_name=-OOoLight
> .ELSE
> application_name=-OOo
> .ENDIF
> .ENDIF
>
> .IF "$(USE_SHELL)"!="4nt"
> all_sdfs:=$(shell cd $(PRJ)$/source && ls -1 *$/{localize.sdf
> localize${application_name}.sdf})
> .ELSE # "$(USE_SHELL)"!="4nt"
> all_sdfs:=$(shell $(CDD) $(PRJ)$/source && find * -name {localize.sdf
> localize${application_name}.sdf})
> all_sdfs!:=$(subst,/,\ $(all_sdfs))
> .ENDIF # "$(USE_SHELL)"!="4nt"
>


Mime
View raw message