Edgewall Software

Version 44 (modified by Jeroen Ruigrok van der Werven, 11 years ago) ( diff )

We don't need additional goals anymore.

Localization (L10N) of Trac

This page is here to propose and discuss Trac changes to support localization (L10N).

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


  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.
  4. Run python setup.py build
  5. Run python setup.py install

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.


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.


  • 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.


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. 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.


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


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 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.


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

Temporary Workaround: Template Translation

Can it be useful? I think so. trac-0.9.1-templates-pt-br.tar.gz

Temporary Workaround 2: gettext support for trac 0.9 and mod_python

Adding this patch and this other patch to trac-0.9.0 you can translate almost all the strings that are not from the templates or the database. Using the patch and a set of translated templates you can use the program in your language easily (the solution is suboptimal, as you can only use one language for each project, but at least it is localized).

To translate it put your self on the trac source dir and do:

  xgettext -o trac.pot `find trac/ -name '*.py' `

Translate the trac.pot to your language (I usually copy it to $LANG.po, on the example I'll use LANG=ca) and compile the translations:

  msgfmt ca.po -o /usr/share/locale/ca/LC_MESSAGES/trac.mo

I've only tested the patch with mod_python, to enable the translations on the apache config I've added the TracLocale option after setting the PythonHandler to the trac one:

  PythonHandler trac.web.modpython_frontend
  PythonOption  TracLocale ca_ES.UTF-8
Note: See TracWiki for help on using the wiki.