|
|
L10N and I18N ProjectThe major
target of the L10N and I18N project is to provide tools and workflows
for localization (l10n)
and
internationalization
(i18n). Whereas the focus of the localization is more on translation
and l10n testing, the focus of internationalization is on the
functionality of the product that need to be internationalized. News - Sun and OOo Community Localization
-
QA Weekend in Essen, Germany: Ales
Cernosek, Petr Dudacek, Berit Bonde and Sven Klawitter from
Sun/Globalization attended the event on March
25-26. Read here
more words on the QA & l10n weekend in Essen.
Localization - l10nWelcome to the Localization project! OpenOffice.org is localized in quite a number of languages. As an overview of the languages and the native language communities engaged in this project, have a look at: http://l10n.openoffice.org/languages.html. In order to localize OpenOffice.org into your own language, the major steps to follow are:
For each of the above milestones there are tools and processes to help you getting the localized product you want. Here below you'll find useful links to tools and instructions on how to proceed depending on the localization areas you are interested in:
Internationalization – i18nThe i18n framework (mostly implemented in module i18npool) offers support for Western languages, Chinese, Japanese and Korean (CJK) languages and for languages that need Complex Text Layout (CTL) like Arabic, Hebrew, Indic languages and others. Functionality that is needed to internationalize applications like an office suite includes:
To support a new locale often nothing more has to be added than an entry in the language listbox and a set of locale data to be able to select the locale as the default document language, apply its number formats, list index entries in their correct order and have the typical outline numbering available, just to name a few. The locale data file needs to be available during build time and is compiled into a library, but except an entry in a table responsible for loading the correct library and a makefile entry no code changes are necessary. Note that mere UI localization does not even need corresponding locale data being available. Only in a few cases it is necessary to implement specialized breakiterators or collation, calendars, transliteration into different numeral systems, or other language specific algorithms. For such tasks there is an Modules
I18N: Some ideas where we think some help would be useful:
IssueTracker queries of ToDo items:
|
||||||||||


