openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <>
Subject Re: OpenOffice localization tasks
Date Fri, 12 Oct 2012 09:50:44 GMT
I know the feeling of inheriting software and procedures, that is not
always easy...but also a possibility to clean up. In my experience when you
have responsibility for a procedure over a very long time, it tends to be
difficult to change it.

I had a look at the translation table and they are mostly standard
programs, that can pretty easy be adapted, no big deal. You must be using
other programs to:
a) split sdf file to po files
b) collect po files to sdf file
c) generate release tree files from sdf file
or have I overlooked a feature in the source ?

It is true that in old days sun had a proprietary tool (I know it from the
UNIX line) and I think it is a safe assumption that it worked with sdf

You are right my proposal is no revulotion merely an evolution :-)

However there is a big difference, today you throw away the po files and
generate them new everytime, because the projects files are considered the
originals. Doing this means that translators cannot keep information
easily. Secondly in my proposal I get rid of the sdf file, which seems to
be a real unnecessary step.

Having the po files in a source control system, will also make it a lot
easier to determine changes in the translated part, also during
translation. Today you only store versions of the regenerated release tree
files. If the translators works with source control, it is also a lot
easier to check if files have been proofread/reviewed and compare changes.

I could be fun to try it on a small scale like e.g. convert localize.cxx to
generate a po file.

On 12 October 2012 11:32, Jürgen Schmidt <> wrote:

> On 10/12/12 10:46 AM, jan iversen wrote:
> > I agree with you at the end of day we need to have a working solution and
> > that can then over time evolve.
> >
> > I have a couple of questions about the process:
> >
> > 1) how many (rough number) conversion/extract programs do you have ?
> DISCLAIMER: I was not responsible for this before ;-)
> In
> starting line 49 you can see the extensions of files that can contain
> localization strings. The second column lists the used tool to extract
> from these files.
> It seems that we have 9 tools whereas one tool get called with different
> options on different extensions.
> > 2) is the sdf file used solely as an intermediary file to create the .po
> > files and create the language files used in the different release trees ?
> Yes, I think so. But I can't say for sure, I think the sdf file was used
> in the past Sun internally to do the translation, probably with
> proprietary tools as well. Later it was extended to use Pootle to
> improve the collaboration with the community.
> >
> > I am just thinking about a process like this ?
> >
> > -- have a database (or file storage) with all po files for all languages,
> > INCLUDING one EN-EN, this is the repository. which should be kept under
> > source control.
> >
> > When a new release is made go through the following steps:
> > a) convert the release tree files to one PO file EN-EN (this would need a
> > change of the current extract programs)
> > b) compare the new EN-EN PO file to the existing EN-EN PO file, and
> create
> > a delta file (With source control this is quite easy)
> > c) update/merge the language EN-XX PO files according to the delta file.
> > (this is a simple modified merge in the source control)
> >
> > d) get the changed language files translated, e.g. through the pootle
> server
> >
> > e) convert the translated EN-XX PO files back to the release files (this
> > would need a change of the current convert programs).
> >
> > I think you avoid many problems by defining the project (release tree)
> > files as generated files and not as original files.
> isn't it very similar to the process today? Ok we have the sdf
> conversion step as additional step but the rest seems to be similar.
> When we have new string to localize, a new sdf files is create and
> converted to template files for Pootle. The related Pootle project gets
> updated and merged with the new templates. The result is a not complete
> translated project with the missing delta. This delta gets translated
> and the result get converted back in sdf.
> Pootle works internally with a database and the po files gets synched
> into the database and back.
> In pootle you can easy navigate to the untranslated strings and I hope
> offline tools allow this as well.
> In the end we would benefit from getting rid of the sdf files because it
> is one unnecessary conversion step where errors can happen.
> Juergen
> >
> >
> >
> >
> > On 12 October 2012 10:03, Jürgen Schmidt <> wrote:
> >
> >> On 10/11/12 7:05 PM, Alexandro Colorado wrote:
> >>> On 10/11/12, Michael Bauer <> wrote:
> >>>> The latest versions of Pootle have a feature called AmaGama which acts
> >>>> as a cross-OS translation memory. For offline, there's Virtaal.
> Perhaps
> >>>> not ideal for mainstream translation work like newsletters and novels
> >>>> etc but I've found it very efficient for software localization.
> >>>>
> >>>> Michael
> >>>>
> >>>
> >>> I like Lokalize for KDE, the shortcuts and different layout makes me
> >>> work faster on switching from one string to the next. Also has good
> >>> TM.
> >>
> >> We can talk a lot about a new tooling or new format but in the end the
> >> work have to be done and it is far more complex when you analyze what we
> >> have and use in the code.
> >>
> >> We collect translation strings from various different formats and create
> >> one big sdf file (en-US) which is used as template for all other
> >> languages. We convert and split the one big sdf in many pot files. After
> >> translation the po files are converted back into one big sdf file for
> >> each language. Several different tools extract the strings from the sdf
> >> file and create the final target files that can be used in build (xcu,
> >> property files, help files, ...)
> >>
> >> Juergen
> >>
> >>
> >>
> >>
> >
> >

Jan Iversen
Tel. no. +34 622 87 66 19

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message