Localization of OpenOffice.org 2.0

 

This file contains work in progress. 

The contents of this pages might (and probably will) change often without warning.

 

 

Last edited 06/08/2006

 

The document is aimed at new localizers who have not necessarily had prior contact with OpenOffice.org or with the world of Open Source.

 


 

Document Index

Planning and preparation

 

1) What you need to know

2) Think about your e-mail address

3) Install OpenOffice

4) Check support for your script

5) Register in OpenOffice

6) Join the localization mailing list

7) Become an OpenOffice.org contributor

8) Announce your intention to undertake the localization project.

9) Plan your work

 

Patching (modifying the source to include your language)

 

10) Include the language in the "Language (locale setting) Dialog Box"

11) Define the default fonts for the language (locale)

12) Font fallback

13) Glyph fallback

14) Prepare an OpenOffice Locale

15) Prepare the patches that will be needed when including the locale file

16) Assure that your script is correctly classified

17) Include your locale in the installation set

18) Configuration options for installation.

19) When your translation is finished, include the language in the build environment

20) Collation (correct alphabetic order for a given locale).

21) Number transliteration

22) Numbering of paragraphs in local script numbers and letters.

23) Outline numbering customization

24) Wizards

25) Special case of languages not supported by Windows

26) Localisation in the help system

27) Localisation of other images

28) Special case of languages that use Complex Text Layout scripts

 

Translation

 

29) Translation

 

 


 

 

1) What you need to know

Localizing OpenOffice.org does not require highly specialized knowledge of programming or of the Open Source world. It does not require either knowledge of a specific operating system, such as Linux. You can localize OpenOffice on MS Windows if you want to. Once you have done it, your localized resources can be very easily used to localize OpenOffice.org in other platforms (if your language script is supported by those platform, or less easily if this basic support is missing).

You do need to understand how to download programs and data from the Internet, how to install them and how to run them (following detailed instructions). You also need to subscribe to at least one mailing list in which localization of OpenOffice.org is discussed.

OpenOffice.org – as the world of Open Source in general - is a collaborative effort. There is no reason whatsoever for which somebody should do anything that you need or want, including fixing bugs, adding new features or accepting patches. You need to be polite, patient, and – if you really want something – charming and convincing… or learn how to do it yourself. There are a lot of people in the mailing lists that will be happy to help you if you ask in the right way.

The table of languages presently supported and ongoing localization projects is in: 
http://l10n.openoffice.org/languages.html

Check it to make sure that there is not already a localization project for your language. If there is one, write to the person that appears as project contact, to know the status of the project and see if it is makes sense to participate on it.

Localizing OpenOffice.org is not a small task, and it has many levels. The lowest one is to assure that OpenOffice.org works correctly in your script (if it is not the Latin script), as it allows people in your country to work using your script, even if the interface of OpenOffice.org is in English or other foreign language. This might be a task that you can do by yourself, but translating the whole OpenOffice.org interface to a new language is a large task, requiring over one man/year, so several people should be involved.

Localization of OpenOffice.org involves:

  • Assuring that OpenOffice.org can work with your script in the platform in which you want to use it.

  • If they are not already there, assuring that some changes are made in the OpenOffice.org source, so that the program recognizes your language as one of the languages it can work in.

  • Translation to your language. Translation has different levels. The first one is translating the menus and messages of the program itself (around 22.000 messages altogether for all applications in OpenOffice), the second one includes also the translation of the help pages of OpenOffice.org, not a small task. The third level adds the development of documentation for OpenOffice.org in your language. If you still have resources after all this, you can complete the work by developing OpenOffice.org training materials in your own language.

But, before we go into details about all this, there are a few things that you might want to do in order to be prepared to face a localization project...


 

 

2) Think about your e-mail address

If you start a localization process, you will have to subscribe to a number of mailing lists, and your e-mail address will end up running around, and probably receiving a lot of spam. We recommend that you consider using for the whole localization process (and not only for OpenOffice) an e-mail address that is different from your personal mail address.

 

 


 

 

3) Install OpenOffice

You have to become familiar with the programs that you are going to localize. If you are not a regular user, we recommend that you change to OpenOffice.org and use it in your everyday work.

We recommend that you install the version that you are going to localize (probably the last stable release). You can find it in:

http://download.openoffice.org/index.html

Also, later on, if you find and file issues for the OpenOffice project, and want to follow if and know when corrections are integrated, you might also want to download and install the latest available build: Check for it at:

http://download.openoffice.org/680/index.html  

Each one of these programs will be between 60 and 80 Megabytes in size.

 


 

4) Check support for your script

It might be that OpenOffice.org does not work with your script. In this case you have to try to get such support.

  • On Linux, OpenOffice 2.0 is supported by version 2.6 of IBM's ICU (International components for Unicode) library. ICU does accept code supporting new languages. You should write such code thinking that it has to work with the current version, as well as with version 2.6. The you need to add your changes to OOo's current patch for ICU, at:

http://external.openoffice.org/source/browse/external/icu/icu-2.6.patch

This patch file MUST NOT be created manually.

There is a dmake target that does this from the sources available under ${INPATH/misc/build/icu/ after the module was built once, and files were modified: dmake create_patch

You have to create the patch on a Unix or Linux platform, using Windows will create the wrong patch.

Language support has several levels, including collation (alphabetic sorting), cursor movement within your script, hyphenation...  if you want to go further into these, you should consult this document.

  • On MS Windows, OpenOffice.org receives script support for CTL languages from Microsoft's Uniscribe engine, contained in the file usp10.dll. If you want to try to get support for your language in such engine, you should get in touch with Microsoft (don't tell them that it is for OpenOffice, though).

  • On Mac...  HELP WANTED. Somebody please write this section.


 

5) Register in OpenOffice

You need to register as a member of OpenOffice.org. This will allow you to subscribe to mailing lists, submit issues and information that you want included in the program (patches that are needed for your language), etc…

To register just go to www.openoffice.org and click in Register, on the top left corner of the screen.

In the next screen you will be asked to provide a login (your name, initials, or anything you want) and the e-mail account in which to want to receive all the mail coming form OpenOffice. Once you enter this data and hit register, an e-mail will be sent to your e-mail account with your password. With the username that you have provided and the password, you can now login in the main page of the website.

Once you are logged in, you can select the MY PROFILE entry in the menu at the left of the page. There you can change your password to one you can remember better or you can change the e-mail address to which you receive e-mail related to OpenOffice.

What OpenOffice.org actually does is to create an e-mail account YourLogin@OpenOffice.org that is redirected to the e-mail address in which you want to receive OpenOffice.org related mail.

 


 

6) Join the localization mailing list

Prior to starting the localization process for OpenOffice.org you should join the OpenOffice localization mailing list. This mailing list is the means of communication with the people in OpenOffice.org that does certain parts of the localization process, as well as with other localizers that might help you figure out specific parts of the localization adventure. It will become your main window into the world of OpenOffice.org, unless you become involved in other developments outside localization.

To join this mailing list, and after logging-in in the OpenOffice.org website, go to:

http://l10n.openoffice.org/servlets/ProjectMailingListList

scroll down until you see

dev@l10n.openoffice.org

Now you have to decide if you want to receive the e-mails from this list one-by-one (when they are sent) or all of the messages sent each day together in a single message (digest format). When you are starting in the process, your interaction with the list might be high, so message-by-message can be a good option when you start, you can always change it to digest mode later.

Click on Subscribe. This will make the OpenOffice.org automatic list manager send an e-mail to your account asking you to confirm your intention of subscribing to the list. Reply to that message following the instructions (which usually are “just hit reply and send, don’t do anything else”).

If you have done everything correctly, you will receive a “Welcome to the list” message… and you are on. From this moment on you will receive all mails sent to the list.

 


 

7) Become an OpenOffice.org contributor

There is one more step that you have to take: becoming an OpenOffice.org contributor. Being a contributor allows you to send data to OpenOffice.org (it actually allows OpenOffice.org to receive data from you without fearing you will ask anything in exchange or claim that some part of OpenOffice.org belongs to you and nobody else, or to a third party).

To become a contributor you actually need fill and sign the form that you will find at

http://www.openoffice.org/licenses/jca.pdf

and fax it to the number indicated in the form and then mail it by postal mail to the address that the form mentions (yes, this is a pain, but a real signature on paper is the only thing that has legal value, and its purpose is to defend you and any other OpenOffice.org users from possible IP claims from contributors).

If you need more information on why you need to do this, follow the link to:

http://www.openoffice.org/FAQs/faq-licensing.html#usinglicenses

Sending the fax and then the letter will put you in the contributors list in:

http://www.openoffice.org/copyright/copyrightapproved.html

And you are ready to start…

 


 

8) Announce your intention to undertake the localization project.

The first step is to let people at OpenOffice.org know that you are going to start the localization project, but before you do this, do check a few things.

-          See if there is already a project for your language in:

 http://l10n.openoffice.org/languages.html

(the order in this list is not alphabetical, check the whole list)

There are several possibilities:

o        Your language is already listed, including all the data and a contact of a project manager. In this case you should contact directly that project manager and try to figure out what is happening, status, etc… It does not make sense to have more than one project for exactly the same language, but maybe the project that is being carried on is different from the one you want to do (for example, there is Khmer for Cambodia, but you want to do Khmer for Khmer-speaking minorities in Vietnam, which is sufficiently different to justify the localization work, and you are prepared to do it). If the project is sufficiently similar, you should consider joining the existing project.

o        The language is listed, but it is either in the FIXME list or it does not include a project contact name. In this case you should write to the list and ask if anybody has information about this project. If there are no answers, you should declare your project as if it was not in the list.

o        Your language is not in the list. Send the necessary information to be added to the list.

The necessary information that you need to gather to be listed in this page (that is, for your project to be considered as an on-going localization project) is:

-          The ISO codes for your language and country (or region). If you don’t know them, follow this links:

Language codes - iso639-2 
Country codes - iso3166-1

     You should also mention if the language is only spoken in a country or it is shared by several countries, and if there are sufficient difference in the way the language is spoken and written in the different countries as to require separate treatment. Based on this data, an internal ISO-CODE for your localization will be assigned by the OpenOffice.org localization team leader according the following rules (taken from RFC 3066):

  1. Use ISO 639-1 if possible. This happens when the language is spoken in a single country (or there are no mayor differences on how it is spoken in different countries), or when the iso code of the language is the same than the iso code of the country (es, fr).

  2. Use ISO 639-2 (three letter language code) if no ISO 639-1 (two letter) code exists.

  3. Use ISO 3166 country code if necessary, to specify versions of languages with the same language code in different countries, such as Spanish in Chile (es-CL), Portuguese in Brazil (pt-BR), or English in the United States (en-US).

-          The name of the language in English.

-          The Microsoft locale ID, in decimal and hexadecimal formats. You can find this numbers in:

http://www.microsoft.com/globaldev/reference/lcid-all.mspx

If your language does not appear in the list, then say so in the OpenOffice Localization mailing list and the language will assign an OpenOffice internal number. This number is used for the cases in which information is stored or read in Microsoft file formats.

-        Inform about the script of your language. Does the language use Latin script? Does it have its own script? If so, what family does the script belong to, specifying if it is Indic, if it uses use pictograms, if it is written from right -to-left, etc... and any other information that might be relevant, including character sets that can be used to render (show) it.

-          Give a contact e-mail address for the manager of your localization project (probably you).

Note: You might see that most languages in the language table have a language number. This is because localizations prior to version 2.0 had to be assigned an internal language number, but it is no longer the case.

If you want to start a new project, you should write all the above information in an e-mail to the localization list, indicating your intention to start a localization project, and stating what is the status of the project. The person in charge of the list of localization projects will add your language and data to it, including the current status for your project. At the moment, the person in charge of handling them is localization project co-owner Pavel Janík, but you should not rely on specific names given in this documentation, as they might change.

 


 

9) Plan your work

And now you are ready to start your localization project. Next we will go one-by-one, through all the changes that need to be done to OpenOffice in order to work in your language and script, using your local conventions in numbers, and the preferred fonts for your script.

These steps are not specially complicated, and we will try to explain them to you very clearly, but they might take sometime. Some of them require time from other people at OpenOffice who will not always be available, and who probably already have a long list of tasks they have to get to before they can help you on your localization. You should start the actions, and do your part of the work, and then wait until the right people have the time to integrate them in the source.

You should also start looking at the translation part of the project. Translating OpenOffice requires gathering or developing a wide range of computer, mathematical and accounting terms in your own language, a glossary. If you do not have such a glossary, you should start working on it as soon as possible, because it will probably take at least two or three months to gather all the information.

If you already have a glossary, then you can start already on the translation of the messages, in parallel to the technical work

 


 

10) Include the language in the "Language (locale setting) Dialog Box"

Check the latest build to see if your language appears in the language dialog boxes. To do this go to ToolsàOptions, and there click on Language Setting, and in there in Languages.

 

 

 

Search for the name of your language in the Locale Setting dialog box. If it is not there, you have to request having it included.

To request it, you should file an issue requesting it. To do this, login into the OpenOffice website, then click on File Issue on the left hand menu… go to proceed in the next page… click in the component l10n in the next one… are you are ready to file it. Select version current, subcomponent code, type ENHANCEMENT, Summary Inclusion of language xxxx in the Locale Setting dialog box, in the text box politely request the inclusion of your language in the locale setting dialog box… and hit Submit. The system will ask you if you want to attach a file and what type, skip this… and finished.

 

After you file the issue, it is a good idea to send an e-mail to the dev@l10n.openoffice.org mailing list (yes, the one you are already subscribed to) saying that you are starting localization to your language and that you have requested inclusion in the Locale Setting dialog box in issue xxxxx. This will make people who are in charge of localization aware of the fact that the process for your language has started and tell them.

Technically, the process requires:

  • Approval of the name for your language by the project linguist (in both English and German)

  • Preparing patches for some or all of the the following files. If you know how to prepare the patches yourself, or want to give it a go, this will probably speed up the process, as it will be less work for somebody else who has to do the integration. Before preparing the patches, you should make sure that you language is NOT in those files (for the version that you want to localize, look into How to prepare a patch for more information). The files are:

When you click on any of the above three filename, your browser will go to the page in which all the versions (also old ones) of that file are stored. In that page you have to look for the version of the file that you are looking for. Please look into How to prepare a patch to know which version of the file you need to look into.


 

11) Define the default fonts for the language (locale)

 

For each language, OpenOffice allows us to define what fonts should be use by default for characters in your language. In this section we can define, for example, which font will be used by OOo Writer as default when you use your own language or script, or which font will be used by the user interface for your localized version of OpenOffice 2.0.

 

Definition of the font default table for your language requires the modification of the file VCL.xcu. If you have OpenOffice installed in your computer, this file is in:

 
<OOoDir>/share/registry/data/org/openoffice
 

(where <OOoDir> is the directory in which OpenOffice is installed)

 

You can find the latest versions of this file in:

officecfg/registry/data/org/openoffice/VCL.xcu

The file is divided into blocks (called nodes), one for each language. The first line of the node for a language includes the standard ISO code for the language.

 

There are two different cases you have to consider here.

 

1)      If your language uses Latin characters (ISO-8859-1) and you are happy with the default fonts for English. You need to have two lines added to this file:

 

+ <node oor:name="YourLanguageCode" oor:op="replace">
+ </node>
 
For Swahili, for example, these lines will be:
 
+ <node oor:name="sw" oor:op="replace">
+ </node>
 

 

2)      You language uses a different script. Find in the file a language that is somehow similar to yours (at least in the same group, either Latin, or Asian (Chinese, Japanese, Korean) or CTL (Complex text layout, including Indian and some Southeast Asian languages). For example, for Khmer we have taken Thai as the model.

 

Copy the node for that language (that is, the block of lines that refers to that language, from <node to </node>), change the language code of the new node to the code of your own language. Then, in each one of the sections, change the font list to a set of fonts that support your language (fonts to which OpenOffice will change if it finds a character from your languages).

 

A node looks like this:

 

<node oor:name="km" oor:op="replace">

   <prop oor:name="UI_SANS" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

   <prop oor:name="CTL_DISPLAY" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

   <prop oor:name="CTL_HEADING" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

   <prop oor:name="CTL_PRESENTATION" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

   <prop oor:name="CTL_SPREADSHEET" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

   <prop oor:name="CTL_TEXT" oor:op="replace" oor:type="xs:string">

    <value>Khmer OS System;Khmer OS;UniKhm</value>

   </prop>

</node>

 

You can see that fonts are separated by the ‘;’ character. You have to use the internal name of the font, the one that appears on your font menu when you select fonts in OpenOffice or any other program (not the name of the file that contains the font). This names might have spaces, this is not a problem, include them. Spaces are significant, so do not put spaces before or after the ‘;’ signs, nor at the beginning or the end of the font list.

 

You might select different substitution fonts for different application, each one of prop statements refers to different tools or situations.

 

If your language is not supported by ISO-8859-1, the first font that is listed in UI_SANS will be used by OpenOffice to display the applications' menus.

 

Don’t forget that this file will be used in several platforms and by people who might have different fonts installed. Include in your list fonts for these platforms; if you know them (Macintosh typically has different fonts). Try to assure that any user will at least have one of the fonts that you have included in the list.

 

Warning: the VCL.xcu file is a UTF-8 file, it can be damaged if edited with a non-utf8 enabled editor. Patches should always be in UTF-8.

 

When you have finished with this file, and made sure that this is what you really want, you have to create an issue for the Localization (L10n) project, and submit a patch  for file officecfg/registry/data/org/openoffice/VCL.xcu. To submit an issue you first need to login into the OpenOffice website, then hit File Issue on the left hand menu… go to proceed in the next page… click in the component l10n in the next one… are you are ready to file it. Select version current, subcomponent code, type PATCH, Summary Patch for VCL.xcu for language…., and hit Submit. The system will ask you if you want to attach a file and what type. Attach the patch that you have been working on and… submit it. You are done.

 

 


12)  Font fallback

In case a font used in a document is not available in a computer in which it is opened, OpenOffice has to use another font to represent the text. A large number of these 'fallback fonts' are defined in OOo 2.0, for the most usual latin and CJK fonts. You can nevertheless, add new font substitutions (font fallbacks) for the particular fonts of your script, or change the existing fallback fonts in your own private build. Using fallback fonts is important, as you do not want a font to be automatically replaced with some other font that perhaps has different width, size or other characteristics that turn a document into a mess.

Font fallbacks should be defined for at least the fonts defined in the default font lists (see chapter 11) .

The font fallback table that establish the relationships between the fonts is defined in the <node oor:name="FontSubstitutions"> of the file:

officecfg/registry/data/org/openoffice/VCL.xcu

As an example, you can take this node, in which the fallback fonts for the Korean font 'Kodig' are defined

 

<node oor:name="kodig" oor:op="replace">

        <prop oor:name="SubstFonts">

          <value>gulim;gulimche;sundotum;baekmukgulim;dotum;andalesansui</value>

        </prop>

        <prop oor:name="SubstFontsMS"><value/></prop>

        <prop oor:name="SubstFontsPS"> <value/> </prop>

        <prop oor:name="SubstFontsHTML"><value/></prop>

        <prop oor:name="FontWeight"><value>Normal</value>

        </prop><prop oor:name="FontWidth"><value>Normal</value></prop>

        <prop oor:name="FontType"><value>CJK,CJK_KR</value></prop>

</node>

If you want to define your own font fallback nodes, you should include them in this list, and send a patch for them.

Note: the example contains lines for several different properties (such as SubstFontsMS) that are empty. They have been included here to make you aware of the existence of the properties, but if you create your own substitution node, you should only include property lines for which you actually have some data. In our example, the following lines could be eliminated without affecting the node:

        <prop oor:name="SubstFontsMS"><value/></prop>
        <prop oor:name="SubstFontsPS"> <value/> </prop>
        <prop oor:name="SubstFontsHTML"><value/></prop>

Names of fonts in this section must be normalised. All characters must be in lower-case letters and spaces, numbers or other non-letter characters should be eliminated (ignored) in the normalised version of the name. For example, if you have a font called "Kt BT 3", in this node you would have to include its normalised name, which is: "ktbt".

When adding a new font like Kodig also the substituted fonts should get a fallback to it. That means that e.g. gulim should fall back to kodig, sungulim should fall back to kodig, etc. This method is clearly unfriendly, as it adds quadratic complexity. Promises to look into it in OOo 3.0 have been made.

Another issue that you need to keep in mind is that a font might sometimes have more than one name, such as having an English name and a localized name (some CJK fonts even have three names, in English, Japanese and Chinese). If you use the wrong name, the font might not be found, so a "localized font-name table" is now used to relate the differenet names. In OOo 2.0.0 the ImplLocalizedFontName array in vcl/source/gdi/outdev3.cxx is currently used for this, but in the future OOo plans to provide a mechanism to specify font name translations in VCL.xcu instead.

 

 


13) Glyph fallback

There are situations when a script is used (e.g. in a document or in the UI) which the selected font does not support.  E.g. Times does not support Khmer script. It could happen that Khmer script is used but the Times is active. OOo detects that the font does not cover Khmer and tries to do something reasonable by temporily selecting an alternative font, which supports the script.

 

The difference between "font fallback" and "glyph fallback" is, that in the "font fallback" case the selected font is not available. In the "glyph fallback" case the font is available, but some of the text rendered in the original font is not supported by the font.

 

For most localization projects you will not to do anything about glyph fallback, in which case you could just ignore this section. You will only need to include a font for your script in the glyph fallback font list if - after having defined font defaults in VCL.xcu - you are still having problems with the display of your script in the UI or some documents.

The current list of glyph fallback fonts is hard-coded in file:

vcl/source/gdi/outdev3.cxx

but this will probably be changed in subsequent versions of OOo.

To add a fallback font for your script in this file you need to look for aGlyphFallbackList[] and add your font to it. Please see that fonts of different types are ordered in lines, with an empty string at the end of each line. Add a line to this list with similar characteristics. The name of the font must be normalised, that it, it must be entirely in lower-case letters and whithout spaces, numbers or other non-letter characters. For example, if you have a font called "Kt BT 3", in here you would have to include its normalised name, that is: "ktbt". Your line in the file would be:

      "ktbt", "",

 


 

14) Prepare an OpenOffice Locale

 

Please look in How to prepare an OpenOffice Locale

 


 

15) Prepare the patches that will be needed when including the locale file

 

When including the locale file in OpenOffice, it is also necessary to include information about this locale in a couple of files. You should prepare the necessary patches for files:

i18npool/source/localedata/localedata.cxx
i18npool/source/localedata/data/makefile.mk

And for one (and only one) of the following:

If the language is some form of English (en_XX), then include it in:

 i18npool/source/localedata/data/localedata_en.map

If it is some form of Spanish (es_XX), then modify:

 i18npool/source/localedata/data/localedata_es.map

If not being English or Spanish, it is a county in the Euro zone, then modify:

 i18npool/source/localedata/data/localedata_euro.map

Otherwise, modify:

 i18npool/source/localedata/data/localedata_others.map

  

 

16) Assure that your script is correctly classified

 

All the scripts that have at this point been defined in Unicode have been classified in OpenOffice as Latin, CTL (indic, left-to-right) or Asian (Chinese, Japanese Korean). If your script is CTL or CJK and it has just been added to Unicode, you might want to make sure that it is listed in the file:

offapi/com/sun/star/i18n/UnicodeScript.idl

If it is not, it has to be included in that file, and then its range has to be added to the file:

i18npool/source/breakiterator/breakiteratorImpl.cxx

 

 


 

17) Include your locale in the installation set

 

In order to have installation sets work correctly for your language, modifications are needed in the following files:


instsetoo_native/inc_openoffice/windows/msi_languages/Langpack.ulf

 

You need to add a block of the style:

 

	[OOO_LANGPACK_NAME_1107]

	en-US = "Khmer"

	de = "Khmer"
	[OOO_LANGPACK_DESC_1107]

	en-US = "Installs Khmer support in %PRODUCTNAME %PRODUCTVERSION"

	de = "Khmer"

Please note that in this case 1107 is the Microsoft locale ID for Khmer in decimal format, you should include the one for your language, which you should have obtained already at this point, but just in case, you can find it in:  http://www.microsoft.com/globaldev/reference/lcid-all.mspx

 

-------------------


setup_native/source/win32/msi-encodinglist.txt

 

You need a line of the type

 

km    0  1107   # Khmer

that includes your ISO language code, the ANSI code-page number for the script, the Microsoft locale ID number (same as in the prior file)... and, if you want, a comment to say which language it is. Warning: ANSI code page number 0 does not seem to work presently, for Unicode languages. If this is the case, please consult issue 47857.

 

---------------------

In file  scp2/source/ooo/file_ooo.scp file you need to make sure that - if your language is a CTL language - the file Common-ctl.xcu is installed, and if it is a CJK language, Common-cjk.xcu and Writer-cjk.xcu get installed. Look for these file names within file_ooo.scp and a a new line for your language. As an example, for Khmer (km) - a CTL language - you should add the line in bold below:

File gid_File_Registry_Spool_Oo_Common_Ctl_Xcu

    TXT_FILE_BODY;

    Styles = (PACKED,MAKE_LANG_SPECIFIC);

    Dir = gid_Dir_Share_Registry_Modules_Oo_Office_Common;

    Name (th) = "/registry/spool/org/openoffice/Office/Common-ctl.xcu";

    Name (hi-IN) = "/registry/spool/org/openoffice/Office/Common-ctl.xcu";

    Name (ar) = "/registry/spool/org/openoffice/Office/Common-ctl.xcu";

    Name (he) = "/registry/spool/org/openoffice/Office/Common-ctl.xcu";
    Name (km) = "/registry/spool/org/openoffice/Office/Common-ctl.xcu";
End

 


 

18) Configuration options for installation.

 

If you would like to change some configuration options, such as having a multi-language installer start by default in a language different from the language used in installation, you should look into this page. This is specially interesting for languages that are not supported by MS Windows and need to build multi-lingual programs, so that English (or other) can be used as an installation language, but then the program is directly installed in your language.

 

 


 

19) When your translation is finished, include the language in the build environment

 

Your language code, as defined in http://l10n.openoffice.org/languages.html, must be included in the list specified in file:

solenv/inc/postset.mk

Languages are usually not included in this file until they are ready for building. In private builds you do not have to modify it if you run configure with e.g. --with-lang="en-US cs xy" where xy is the ISO code for your language.


 

20) Collation (correct alphabetic order for a given locale).

 

If you consider that OpenOffice does not collate (sort aphabetically) correctly for your language, you can patch it to sort in a different way when your locale is used. If this is the case please look into this document on Collation in OpenOffice 2.0.

 


 

21) Number Transliteration

If your script is new to OpenOffice, you need to indicate to OpenOffice.org 2.0 what are the Unicode code-points of the digits in your script, as well as separation characters, etc, so that the numbers in your script can be used in Calc, or for numbered lists or schemes.

 

This information is included in file:

 

i18npool/source/nativenumber/data/numberchar.h

 

You should check to make sure that information about the numbers in your language (not script, every language) is included here, as well as separation characters, etc.

You also need to include your script in both the natnum1Locales[] and natnum1[] arrays of file:

 

i18npool/source/nativenumber/nativenumbersupplier.cxx

You should send a single patch that covers changes to these two files.

 

If this is already done, then you can - for example - format cells in Calc by using:

 

[NatNum1]

 


 

22) Numbering styles of paragraphs in local script numbers and letters

 

It is possible in OpenOffice.org Writer to number paragraphs using local script numbers instead of Latin numbers. You can see the defined styles in OpenOffice.or Writer in Format-->bullets and Numbering-->Numbering type tab. In order to change these styles, you need to make the necessary changes in this part of your locale file.

 

If you want to use the letters of your script instead of numbers (equivalent to using A, B, C... in English), then it is a little mor complicated, as you have to define the style, and then the letters that you have included in <IndexKey> in the locale file will be used. Using letters requires patching two files:

 

In:

 

offapi/com/sun/star/style/NumberingType.idl

 

You need to add a new line with a new number, including something like

 

     /** Numbering in Khmer alphabet letters

	 */

    const short CHARS_KHMER = 34;

in which the number is the next one after the last that you find in the file (you should also place for code as last in the fuction).

 

-------------

 

In file

 

i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx

 

you need to include an entry of the type

case CHARS_KHMER:
  lcl_formatChars(table_Alphabet_km, sizeof(table_Alphabet_km) / sizeof(sal_Unicode), number - 1, result);
  break;

in DefaultNumberingProvider::makeNumberingString

 

and then include a line of the type:

        {style::NumberingType::CHARS_KHMER,    NULL, LANG_CTL},

in the correct position in static const Supported_NumberingType aSupportedTypes[]

 

Note that the last element is LANG_CTL, defining the language as CTL (this will appear in the menus only if CTL is activated), here you can also use LANG_CJK or LANG_ALL.

 

-----

 

Finally, you have to define the table of permitted characters (table_Alphabet_km) in file

 

i18npool/inc/bullet.h

with a block such as:

static sal_Unicode table_Alphabet_km[] = {

	0x1780, 0x1781, 0x1782, 0x1783, 0x1784, 0x1785, 0x1786, 0x1787, 
	0x1788, 0x1789, 0x178A, 0x178B, 0x178C, 0x178D, 0x178E, 0x178F, 
	0x1790, 0x1791, 0x1792, 0x1793, 0x1794, 0x1795, 0x1796, 0x1797, 
	0x1798, 0x1799, 0x179A, 0x179B, 0x179C,                 0x179F, 
	0x17A0, 0x17A1, 0x17A2 

};

 

 


 

23) Outline numbering customization

 

In OpenOffice.org Writer you can number different levels of headings into a structured document. The styles in which these outlies are numbered can be seen in Format-->bullets and Numbering-->Outline tab. In order to change these Outline styles, you need to make the necessary changes in this part of your locale file.

 

 

 


 

24) Wizards (REVIEW, how to translate the wizards themselves)

 

OpenOffice.org 2.0 have a number of Wizards and templates to prepare standard documents in a nice style. The templates used by the Wizards are in:

 

extras/source/templates/

Look into the Localization tips page on how to translate them

 

Some information about these can be found in:

If you do not want to go translating the files one by one, Søren Thing Pedersen has developed a python program that extracts the strings, allows you to translate them and puts the translations back.

 

Some of the files have en-US in the name, you should change this to your own locale name.

 

The file

 

installation/extras/source/autotext/lang/en-US/acor_en-US.dat

is a zipped file that contains autocorrect entries

 

You also need to change 01 in the name of

installation/extras/source/misc_config/lang/en-US/starmath01.sms

to whatever your country's numeric code is

 

 

 

 

 


 

25) Languages not supported by Windows

 

OOo for Windows cannot use as intallation languages those who are not supported by Windows. Adding to that, the native Windows installer used MUST be in the same language as the package.

Check the list of Windows XP supported locales in:



http://www.microsoft.com/globaldev/reference/winxp/xp-lcid.mspx

Not in there? And what do we do now ! you will ask, in desperation.

 

No sweat, Ingo Schmidt and Joerg Barfurth have developed a mechanism through which installers for these languages are automatically bilingual in English and in the target language. In these bi-lingual installation sets the installation takes place in English, but the program starts automatically in the target language.

 

You have to use this mechanism if your language is not supported by Windows, or if it is supported in the latest versions (such as W XP-SP2), but for target is much wider, such as wanting to assure that it also works in plain Windows XP or Windows 2000.

 

If you are part of those not chosen my Microsoft, you need to patch file

solenv/bin/modules/installer/globals.pm

The file contains a variable that is instantiated with the list of the unfortunates

@noMSLocaleLangs = ("km","rw");

All you have to do is to create a patch in which your language is added (in alphabetic order please) to this line.


 

26) Localisation in the help system

 

Besides translating the help, it is necessary to actually localise a number of images, as well as some style sheets (which will allow you to use your script in the help, if it is not latin).

 

The images that need to be replaced by local versions are in

default_images/res/helpimg/

You need to create here a folder (with your iso name as folder name) in which you include some localised images. You do not have to localise all of the images. Look into one of the subdirectories (such as km) to see which images have been localised by otherr. then take these images from default_images/res/helpimg/, localise them and create a tar file that contains all the files (path included).

 

You also need to patch the file that indicates available images. All your files included above must be listed in file:

helpcontent2/util/helpimg.ilst

Prepare a patch for this file.

 

Then you have to look at the contents of

helpcontent2/source/auxiliary/

where you need to copy the contents of the en-US directory to a directory with your iso name, and then localise the files. Pay special attention to the fonts defined in the css files, as they mark the script that will be used in the help. If the first font in the lists does not contain your script, then the help will not display correctly. Include these files also in the cat file that you created before.

 

Create an issue to which you attach the tar file with the images and css files. Attach also the patch to helpcontent2/util/helpimg.ilst

 

 


 

27) Localisation of other images

 

Some other images to be localised are in:

ooo_custom_images/industrial/res/commandimagelist/

Look in one of the language directories to see which images need to be localised. The originals are in ooo_custom_images/industrial/res/commandimagelist/

 

Create your original versions, and put them in a tar file, including full paths. Sumbit an issue with the tar file.

 


 

28) Special case of languages that use Complex Text Layout scripts

 

The script needs to be included in:

svtools/source/config/languageoptions.cxx

 

 


 

29) Translation

The OpenOffice software itself  (messages)

 

PO format files that include all the messages that need to be translated in OpenOffice 2.0 (around 22.000 messages) are available.

 

The PO (portable objects) format is a standard format used in translatable files. Specific editors that handle these files facilitate the translation process, and they are often hooked to "translation memory" systems (databases that keep all the messages that have been translated), facilitating also the upgrade process from one version to the next.

 

The translation process described here consists on the translation of the PO files, running checks on them for possible mistakes, correction of these mistakes, and finally conversion of the PO files to a format that is easily acceptable for OpenOffice. The process is technically very simple.

 

For details, please look into the Complete Translation Process page

 

Help

 

PO files that include the information in the HELP files are also available (around 32.000 messages).

 

On how to localize the help, please look at this PDF document written by Frank Peters, you might also want to look into this specification document.

 

Documentation

 

 (***REVIEW***, Search for sources and information)

 

Training materials

 

 (***REVIEW***, Search for sources and information)

 


 

This documentation has been written by Javier Solá as part of his work on a "Localization Toolkit" under a grant provided by the ICT R&D Grants Programme for Asia Pacific. The donors are APDIP (United Nations Development Program), the Internet Society, APNIC, Pan Asia Networking (IDRC), and Asia Media Information and Communication Centre. Copyright is shared by Sun Microsystem, the author and the donors, and is licensed under the same license as the rest of the the OpenOffice documentation.