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:
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:
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).
|
By any use of this Website, you agree to be bound by these Policies and Terms of Use
CollabNet is a trademark of CollabNet, Inc., Sun, Sun Microsystems, the Sun logo, Java, Solaris, StarOffice are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.