Skip to content

start:

How to localize and build OpenOffice inside the L10N-Framework


1. Workflow


First step of localization is to extract all strings and messages out of the source code for translation. The tool localize is a wrapper for different merger and extractors and will be used for extraction.

Result of extraction i a tab separated ASCII file (encoded in UTF8), which contains context information of strings and messages as well as the strings themselves.

An example of those ASCII file can be found here.


Second step is to translate this ASCII file. This could be done by translating the file itself, split it up into different parts to do the work with more than one translator or by importing the file into well known localization tools. Handling of the translation process is not supported by the L10N-Framework.


Third step is to merge back the translated strings into the code. This again is done by localize. In merge mode, localize reads the ASCII file and uses the context information to find the correct source file and the correct position inside the code for inserting the translated strings.


Fourth step is rebuild of the localization targets inside the build environment. This is done by a simple build command.

The process needs information about the target language as a full qualified ISO code (e.g. en-US or de-CH). The ISO code is used internally for language dependent configuration items and inside Java properties.


At the end of step four, a installation set will be created automatically.



2. How to localize


This chapter describes the steps which have to be done to localize the source code and the different source files. The build environment has to be set up before work could start. This is described in Getting_milestone_workspaces.html.


2.1 Language representation


There are several representations of a language inside the build environment. This includes a numeric representation, a symbolic representation and the full qualified ISO code.

Inside L10N-Framework the numeric representation for the localization language will always be 99. The numeric representation is used inside the extraction result file, which has to be translated.

Inside the L10N-Framework the symbolic representation for the localization language will always be extern. The symbolic representation is used inside src and hrc files and also inside the build environment.

The full qualified ISO code for the localization language has to be set by the user.


2.1.1 Table of supported languages inside the build environment


The following table contains all languages supported by the build environment. This languages could be used as source language for localization and also as fallback for not translated text:


Table of supported languages



2.2 Extraction of strings and messages


Strings and messages have to be extracted out of the code before translation. The tool localize has to be used in the following way:


localize -e -i ISO-Code -l Languages -f OutputFile


ISO-Code: the ISO code of the target language.

Languages: The languages which have to be extracted (and their fallbacks)

OutputFile: The file which contains all extracted strings and messages after localize is executed


Example:


localize -e -i de-CH -l 49,99=49 -f ~/MyLocalizationFile.txt


Localize will extract all strings and messages in German and will fill the localization language with German fallbacks. After extraction, ~/MyLocalizationFile will contain the text for language 49 (german) and language 99 (extern). All strings which are not localized in 99 will be filled with language 49.

The lines inside the file are structured like this:


German source 1

Extern translation 1

German source 2

Extern translation 2

...


This means, each second line has to be translated.

A closer definition of the file format can be found here.



2.3 Merging back translated strings and messages


After translation, the localized file (~/MyLocalizationFile in 2.2) has to be merged back into the code.

To do this localize has to be executed like this:


localize -m -i ISO-Code -l Languages -f InputFile


Example:


localize -m -i de-CH -l 99 -f ~/MyLocalizationFile


Localize will merge back the translated strings and messages into the code.



2.4 Rebuild of localized code


After merging back the strings and messages, the code has to be rebuild. Chapter 3 describes how to use the modified build environment to build a localized version of OpenOffice.



3. Rebuild of localized code


3.1 Setting up the build environment


After setting up the build environment like described in Getting_milestone_workspaces.html the following source files will be buildable inside the environment:



File Type

Extension

Explanation

Resource Definition

src, hrc

OpenOffice resource system. Includes dialogs, menus, strings, and messages.

Setup Definition

lng

String and message definitions for the setup program.

XML Properties

xrb

XML format to generate Java properties. Includes resource bundles, strings, and messages.

XML Configuration

xcd

XML format for configuration files.

Templates, Examples, URL-files and additional stuff

*

Different formats with multiple language dependent data. Output of build process will be zip archives




3.2 Rebuild of changed files


If translated strings and messages are merged back into source code like described in 2.3 the code has to be rebuild.

Change the current working directory to the instsetoo or instset module and use the build command for a full rebuild.


build -all


The build command will walk through all source directories of the workspace and will rebuild all effected targets of the merge process.



3.3 Creation of installation set


The installation set will be automatically created at the end of the build process described in 3.2 (if build -all succeed). The installation set will be created into the platform dependent output directory of the instsetoo or instset module (e.g. instsetoo/unxsols3.pro/normal).