openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: OpenOffice localization tasks
Date Fri, 12 Oct 2012 09:32:18 GMT
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 ;-)


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.


> 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

View raw message