incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric b <eric.bach...@free.fr>
Subject Re: [POOTLE]: Proposed approach to bring the Pootle server into a well defined state
Date Mon, 19 Mar 2012 16:00:01 GMT

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 !



> 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"

-- 
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news






Mime
View raw message