Localization (L10N) of Trac

Trac uses ​Babel for localization. Please see source:sandbox/i18n for a work in progress.

The preference panel for language works now (since r6732).

Installation

1. Install ​Babel.
2. Get a svn checkout from the i18n sandbox, e.g. svn checkout http://svn.edgewall.org/repos/trac/sandbox/i18n trac
3. Run python setup.py compile_catalog, you might need to use the force option (-f): python setup.py compile_catalog -f in order to compile catalogs marked fuzzy. If you are interested in just one locale, provide the -l option to specify a single locale to be compiled, for example: -l nl_NL.
4. Run python setup.py build
5. Run python setup.py install

Note that the last two steps are not required if you're developing Trac and you're running it directly from the checkout.

Contributing

The various locale files can be found in the repository under source:sandbox/i18n/trac/locale. The messages.pot is the template file from which the various locale-specific files get created by an init_catalog call to setup.py with the -l locale flag specifier.

For the various languages there are already various tickets logged in which the work on them is tracked.

The following is historical information

Possible Goals

First of all let's define all possible goals. It is understood that not all of them can necessarily be implemented.

Formats

I18N is not only translation, it is also a bunch of other things. Since currency or paper size or units of measurement are not relevant here, the most important aspect besides translation is the format of time and date. Trac, unfortunately, uses the least sensible date format throughout, with the day between month and year. The date format should be configurable, and the default, as this is a technical environment should be ISO 8601, such as 2005-07-29.

Wiki

• We need an easy way to translate wiki pages. It should help and encourage people to translate a particular page into their native language.
• It should be possible to quickly switch between different versions of the same page. May be we should give the possibility to compare different versions on one page.
• We have to give the way to set the prefered language.
• There should be a way to quickly check if the translation is current with respect to the original version. The original version may not always be in english, so there should be a way to know which one is the original.

Interface

For the project to be localized, the actual interface would have to be translated as well. How difficult would it be to translate the interface to say, Japanese?

If possible it should be a user preference, which may require some additional changes. Ideally a single Trac site should be able to serve users in many countries. The interface should be translated and there should be support for translation of custom fields and plug-in's as well as wiki pages.

If possible it may be best if one could come up with an array of the most important terms derived from the wiki pages described below to be used in auto translating the interface.

Terms (Definitions)

Consistent and careful translation of terms like timeline, ticket, report is very important. These terms are used everywhere and must be easy to remember and comfortable to use.

Please note that for many translations there is already work underway in sandbox/i18n, especially under sandbox/i18n/trac/locale. Please see the relevant open tickets.

The way to make up good translations of important terms is to discuss them before using everywhere. The easiest way to accomplish it is to set up wiki pages for different languages. See, for example TracTermsPt, TracTermsPtBr, TracTermsEs, TracTermsFa, TracTermsFr, TracTermsKo ,TracTermsRu, TracTermsJa, TracTermsDe, TracTermsLv, TracTermsPl, TracTermsEl, TracTermsZhCn, TracTermsZhTw, TracTermsNl, TracTermsHu, TracTermsSv, TracTermTr, TracTermsIt, TracTermsCy. Add your own using TracTermsEn as an example.

Other Implementations

How does other software (especially wiki-software) deal with the problem of L10N? This section is devoted to describing and linking existing solutions.

Wikipedia

The famous ​Wikipedia has a huge collection of translations. How do they do it?

Drupal

The Drupal CMS ​http://www.drupal.org has a nice translation unit for its backend. It uses .po-files that can be edit and translated with the poedit ​http://www.poedit.net/ software.

Zope

Zope also uses gettext-catalogs for translation. All basic functionality is provided by the packages ​zope.i18n (language-negotiation, formats for time, date, translation of msgids with languagefallback) and ​zope.i18nmessageid. It also has ​code to use LDML-files (Locale Data Markup Language).

The template-language provides some special attibutes (e.g. i18n:domain, i18n:translate). Translation in python-code works like this (from ​http://svn.zope.org/Zope3/trunk/src/zope/i18nmessageid/messages.txt?rev=65911&view=log)

In this example, we create a message factory and assign it to _.  By
convention, we use _ as the name of our factory to be compatible with
translatable string extraction tools such as xgettext.  We then call _
with a string that needs to be translatable:

  >>> from zope.i18nmessageid import MessageFactory, Message
  >>> _ = MessageFactory("futurama")
  >>> robot = _(u"robot-message", u"${name} is a robot.")

robot looks like a unicode-string and will be translated depending on the negotiated language and the available message-catalogs.

Django

The Python based web application framework ​Django also uses gettext for internationalization, as decribed in ​http://www.djangoproject.com/documentation/i18n/.