XlocaleData (an excerpt from the Developers Guide I18n chapter)
[TOPIC:com.sun.star.i18n.XLocaleData]One of the most important tasks in implementing a new locale is to define all the locale data to be used, listed in the following table as types returned by the [IDL:com.sun.star.i18n.XLocaleData] interface methods:
Type |
Count |
---|---|
[IDL:com.sun.star.i18n.LanguageCountryInfo] |
exactly 1 |
[IDL:com.sun.star.i18n.LocaleDataItem] |
exactly 1 |
sequence<[IDL:com.sun.star.i18n.Calendar]> |
1 or more |
sequence<[IDL:com.sun.star.i18n.Currency]> |
1 or more |
sequence<[IDL:com.sun.star.i18n.FormatElement]> |
at least all [IDL:com.sun.star.i18n.NumberFormatIndex] format codes (see below) |
sequence<[IDL:com.sun.star.i18n.Implementation]> collator implementations |
0 or more, if none specified the ICU collator will be called for the language given in <LanguageCountryInfo> |
sequence<string> search options (transliteration modules) |
0 or more |
sequence<string> collation options (transliteration modules) |
0 or more |
sequence<string> names of supported transliterations (transliteration modules) |
0 or more |
[IDL:com.sun.star.i18n.ForbiddenCharacters] |
exactly 1, though may have empty elements |
sequence<string> reserved words |
all words of [IDL:com.sun.star.i18n.reservedWords] |
sequence<[IDL:com.sun.star.beans.PropertyValues]> numbering levels (no public XLocaleData API method available, used by and accessible through [IDL:com.sun.star.text.XDefaultNumberingProvider] method getDefaultContinuousNumberingLevels() implemented in i18npool) |
exactly 8 <NumberingLevel> entities |
sequence<[IDL:com.sun.star.container.XIndexAccess]> outline styles (no public XLocaleData API method available, used by and accessible through [IDL:com.sun.star.text.XDefaultNumberingProvider] method getDefaultOutlineNumberings() implemented in i18npool ) |
exactly 8 <OutlineStyle> entities consisting of 5 <OutlineNumberingLevel> entities each |
Locale data is defined in an XML file. It is translated into a C++ source file during the build process, which is compiled and linked together with other compiled locale data files into shared libraries. The contents of the XML file, their elements, and how they are to be defined are described in i18npool/source/localedata/data/locale.dtd. The latest revision available for a specific CVS branch of that file provides up-to-date information about the definitions, as well as additional information.
If the language-country combination is not already listed in tools/inc/lang.hxx and tools/source/intntl/isolang.cxx and svx/source/dialog/langtab.src, OpenOffice.org is probably not prepared to deal with your specific locale. For assistance, you can consult http://l10n.openoffice.org/adding_language.html#step1 (Add the New Language to the Resource System) and join the L10N@openoffice.apache.org mailing list (see also http://l10n.openoffice.org/servlets/ProjectMailingListList).
In order to conform with the available build infrastructure, the name of your locale data file should follow the conventions used in the i18npool/source/localedata/data directory: <language>_<country>.xml, where language is a lowercase, two letter ISO-639 code, and country is an uppercase two letter ISO-3166 code. Start by copying the en_US.xml file to your <language>_<country>.xml file and adopt the entries to suit your needs. Add the corresponding *.cxx and *.obj target file name to the i18npool/source/localedata/data/makefile.mk. Note that there is an explicit rule defined, so that you do not need to add the *.xml file name anywhere. You must also add the locale to the aDllsTable structure located in i18npool/source/localedata/data/localedata.cxx. Make sure to specify the correct library name, since it must correspond to the library name used in the makefile. Finally, the public symbols to be exported must be added to the linker map file corresponding to the library. You can use the i18npool/source/localedata/data/linkermapfile-check.awk script to assist you. Instructions for how to use the script are located the header comments of the file.
<LC_FORMAT><FormatElement>
To be able to load documents of
versions up to and including StarOffice 5.2 (old binary file format),
each locale must define all number formats mentioned in
[IDL:com.sun.star.i18n.NumberFormatIndex]
and assign the proper formatindex="..."
attribute.
Failing to do so may result in data not properly
displayed or not displayed at all if a built-in "System" or
"Default" format code was used (as generally done by the
average user) and the document is loaded under a locale not having
those formats defined. Since old versions did merge some format
information of the [Windows] Regional Settings, it might be necessary
to define some duplicated codes to fill all positions. To verify that
all necessary elements are defined, use a non-product build of
OpenOffice.org and open a number formatting dialog, and select your
locale from the Language list box. An assertion message box
appears if there are any missing elements. The errors are only shown
the very first time the locale is selected in a given document.
<LC_FORMAT><FormatElement><FormatCode>
In general, definition of number
format codes follows the user visible rules, apart from that any
non-ASCII character must be entered using UTF-8 encoding. For a
detailed description of codes and a list of possible keywords please
consult the OpenOffice.org English online help on section "number
format codes".
Be sure to use the separators you declared in
the <LC_CTYPE>
section in the number format codes, for example <DecimalSeparator>,
<ThousandSeparator>,
otherwise the number formatter generates incorrect formats.
Verify
the defined codes again by using the number formatter dialog of a
non-product OpenOffice.org build. If anything is incorrect, an
assertion message box appears containing information about the
error.
The format indices 1..49 are reserved and, for backward
compatibility, must be used as stated in
offapi/com/sun/star/i18n/NumberFormatIndex.idl.
Note that 48 and 49 are used internally and must not be used in
locale data XML files. All other formats must be present.
<FormatCode usage="DATE"> and <FormatCode usage="DATE_TIME">
Characters of date and time
keywords, such as YYYY for year, had previously been localized for a
few locales (for example, JJJJ in German). The new I18N framework no
longer follows that approach, because it may lead to ambiguous and
case insensitive character combinations that cannot be resolved at
runtime. Localized keyword support is only given for some old
locales, other locales must define their codes using English
notation.
The table below shows the localized keyword codes:
|
DayOfWeek |
Era |
Year |
Month |
Day |
Hour |
---|---|---|---|---|---|---|
English (and all other locales not mentioned) |
A |
G |
Y |
M |
D |
H |
de_AT, de_CH, de_DE, de_LI, de_LU |
|
|
J |
|
T |
|
nl_BE, nl_NL |
|
|
J |
|
|
U |
fr_BE, fr_CA, fr_CH, fr_FR, fr_LU, fr_MC |
O |
|
A |
|
J |
|
it_CH, it_IT |
O |
X |
A |
|
G |
|
pt_BR, pt_PT |
O |
|
A |
|
|
|
es_AR, es_BO, es_CL, es_CO, es_CR, es_DO, es_EC, es_ES, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR, es_PY, es_SV, es_UY, es_VE |
O |
|
A |
|
|
|
da_DK |
|
|
|
|
|
T |
nb_NO, nn_NO, no_NO |
|
|
|
|
|
T |
sv_FI, sv_SE |
|
|
|
|
|
T |
fi_FI |
|
|
V |
K |
P |
T |
<FormatCode
usage="DATE" formatindex="21"> and
<FormatCode usage="DATE_TIME" formatindex="47">
The formatindex="21"
[IDL:com.sun.star.i18n.NumberFormatIndex] DATE_SYS_DDMMYYYY
format code is used to edit date formatted data. It represents a date
using the most detailed information available, for example, a 4-digit
year and instead of a 2-digit year. The YMD default order (how a date
is assembled) is determined from the order encountered in this
format.
Similarly, the formatindex="47"
[IDL:com.sun.star.i18n.NumberFormatIndex]
DATETIME_SYS_DDMMYYYY_HHMMSS
format code is used to edit date-time data. Both format codes must
display data in a way that is parable by the application, in order to
be able to reassemble edited data. This generally means using only
YYYY,MM,DD,HH,MM,SS keywords and <DateSeparator>
and <TimeSeparator>.
<FormatCode usage="CURRENCY">
The [$xxx-yyy] notation is needed for compatibility reasons. The xxx part denotes the currency symbol, and the yyy part specifies the locale identifier in Microsoft Language ID hexadecimal notation. For example, having “409” as the locale identifier (English-US) and “$” as the currency symbol results in [$$-409]. A list of available Language IDs known to the OpenOffice.org application can be found at project util module tools in file tools/inc/lang.hxx. Format indices 12, 13, 14, 15, 17 with [$xxx-yyy] notation must use the xxx currency symbol that has the attribute usedInCompatibleFormatCodes="true" (see element <LC_CURRENCY> in the locale.dtd file).