Add support for internationalization of templates

[king@…]

Add support for multilingual templates

[jimmy_lee14@…]

That will be great !!

[daniel]

This is definitely a post-1.0 feature.

[mgood]

Tickets #1421 and #1717 have been marked as duplicates of this ticket

For more information see the  FAQ entry on Trac i18n and TracL10N for more information.

[anonymous]

Well, I know it's been delayed to 2.0, but I wanted to say that I need this too. Particularly in Japanese. The bug tracking software my coworkers use (and make me use) are pretty lame, but there is just no way I can make them use something in english.

So you do the roadmap the way you want, but I hope it will be around soon. Anyway, keep up the good work.

[eblot]

A small step (that would nevertheless save a lot of hassle) would be to use UTF8 instead of ISO-8859-1 as standard default encoding for Python files

Would this move be possible in the short term ?

[eblot]

It's not about template-only anymore:

Many strings are now hardcoded in the Python files themselves.

Finishing up the french translation of the current trunk release, I would suggest to the Trac developer to always distinguish names from values in form fields, in both HDF dataset and CS templates.

This is already the case in most of the ClearSilver templates. Nevertheless, I had some troubles with the status of bugs (new/assigned/...) where <select> XHTML tags do not use the "value" attributes, i.e.

< select name="status" >
  < option >new< /option >
  < option >assigned < /option > 
< /select >

would be better replaced with

< select name="status" >
  < option value="new" >new< /option >
  < option value="assigned" >assigned< /option > 
< /select >

(sorry about the extra space chars in the above samples, but Trac does not like -at all- embedded HTML in text area...)

[cboos]

(off-topic) Really?

Testing...

<select name="status">
  <option value="new">new</option>
  <option value="assigned">assigned</option> 
</select>

You can even highlight it using the #!xml directive:

<select name="status">
  <option value="new">new</option>
  <option value="assigned">assigned</option> 
</select>

... or show what it would do using the #!html directive:

new assigned

Seems to work, otherwise it would have been a quite serious bug...

[eblot]

Yes, really. Have a look at #1971.
Trac shows very weird behaviour (such as the exception), but you're right, the issue was not as simple as I first thought.

[anonymous]

Its ready ?

[eblot]

It's ready ?

Check out the milestone: 0.11

[durchanek@…]

Is there any way how non-Python programmer can help with this ticket? This is a really blocker for using Trac by our customers.

[cboos]

Well, I'm afraid not until the infrastructure (I18N) is in place. Then, the localization effort (L10N) will for sure welcome contributions from non-programmers.

Right now, translating the templates and the code is a lot of work, but it has already been done for a few languages (e.g.  th:TracFrenchTranslation) for 0.10-stable. Doing that on 0.11dev is certainly a bad idea, as things are still much in flux there.

0.12 is a more reasonable target for the I18N of Trac.

[durchanek@…]

This is sad, i am afraid that 0.12 is too far. Ok and is it possible to make my own localization for 0.10-stable simply by translating templates? The main question is whether all relevant texts are in templates (which would be nice) or also in Python code?

[eblot]

Replying to cboos:

Doing that on 0.11dev is certainly a bad idea, as things are still much in flux there.

I can witness here that this is definitely a time-consuming (and boring ;-)) task, even for 0.10 series.

BTW, be aware that as the templating system has changed from 0.10 to 0.11, translations made for Trac 0.10 will not be easily ported to the next releases.

[eblot]

Replying to durchanek@gmail.com:

Ok and is it possible to make my own localization for 0.10-stable simply by translating templates?

It depends on how many elements you want to translate.

• Most of the "localizable" elements are located in the templates, which means that it is quite easy to translate.
• However, some dynamically created elements, such as "2 days ago", "edited by <user>", and those ones are not easy to locate in the code. Moreover if you are targeting a language whose characters do not fit in the ASCII set, you need to replace all these strings with Python unicode string within the Python code
• Error messages are hardcoded in the Python code as well
• Finally, ticket status (owned, created, etc.) cannot be translated as is, as their values are used/recognized by the Python code.

The main question is whether all relevant texts are in templates (which would be nice) or also in Python code?

I'm afraid they are in both, and you can add Javascript IFAIR.

If you go down that road, I would suggest that you download the original Trac 0.10.3 release, download the  french translation as well, and compare both trees: that will show you (at least) the locations where translations are required, and some hints about how translation of specific items have been done.

Note that the french translation does not alter the Trac DB contents, which means that you can run both an original, english Trac engine and a translated engine on top of the same database. This leads to some extra Python code that is in charge of translating some elements.

[durchanek@…]

Thanks for clarifying this to me. It seems that easily translated version would be some weird mix of Czech and English words. I will wait until this will be completed and you can bet that Czech translation will be among the first ones ;-)

[axo@…]

registering for notification

[anonymous]

Unsubscribed from this ticket

[jruigrok]

Trunk now has support for L10N.

[cboos]

Is there something that remains to be done for this ticket specifically, or could we consider it's done in trunk, now that there is "support for internationalization of templates"?

[jruigrok]

Closing this. All L10N work is delegated to specific tickets for each language. For i18n we just keep working on that as problems arise.

If specific language tickets are missing, look at the rest of them (l10n keyword) on how to create a new ticket for the language in question.

[olemis@…]

Replying to eblot:

Replying to durchanek@gmail.com:

Ok and is it possible to make my own localization for 0.10-stable simply by translating templates?

It depends on how many elements you want to translate. * Most of the "localizable" elements are located in the templates, which means that it is quite easy to translate. * However, some dynamically created elements, such as "2 days ago", "edited by <user>", and those ones are not easy to locate in the code. Moreover if you are targeting a language whose characters do not fit in the ASCII set, you need to replace all these strings with Python unicode string within the Python code * Error messages are hardcoded in the Python code as well * Finally, ticket status (owned, created, etc.) cannot be translated as is, as their values are used/recognized by the Python code.

I recently sumitted an enhancement proposal (... patch included ;) so as to fix some templates and source code in order to fix some pages which still remain partially translated in Trac 0.11.1. I have found them while testing  a simple solution for Trac<0.12 I18N. In theory (.. it is based on  Babel support ;) this alternative is ready-to-be-used with the following Trac translations (however I have not tried any of them yet ;):

Closed :

#280

Add support for internationalization of templates

Open :

#5469

Translation of Trac to Spanish/Español [es_ES]

#5470

Translation of Trac to Portuguese/Português [pt_PT]

#5471

Translation of Trac to Japanese/日本語 [ja_JP]

#5472

Translation of Trac to Chinese/中文 [zh_CN]

#5473

Translation of Trac to Dutch/Nederlands [nl_NL]

#5474

Translation of Trac to French/Français [fr_FR]

#5475

Translation of Trac to German/Deutsch [de_DE]

#5476

Translation of Trac to Portuguese/Português [pt_BR]

#5477

Translation of Trac to Korean/한국어 [ko_KR]

#5478

Translation of Trac to Russian/Русский [ru_RU]

#5479

Translation of Trac to Latvian/Latviešu [lv_LV]

#5480

Translation of Trac to Polish/Polski [pl_PL]

#5481

Translation of Trac to Greek/Ελληνικά [el_GR]

#5482

Translation of Trac to Traditional Chinese/正體中文 [zh_TW]

#5486

Translation of Trac to Hungarian/Magyar [hu_HU]

#5487

Translation of Trac to Swedish/Svenska [sv_SE]

#5488

Translation of Trac to Turkish/Türkçe [tr_TR]

#5489

Translation of Trac to Italian/Italiano [it_IT]

#5592

Translation of Trac to Czech/Česky [cs_CZ]

#6382

Translation of Trac to Farsi/پارسی [fa_IR]

#6385

Translation of Trac to Welsh/Cymraeg [cy_GB]

#6430

Translation of Trac to Thai/ไทย [th_TH]

#6629

Translation of Trac to Vietnamese/Tiếng Việt [vi_VN]

#7177

Translation of Trac to Norwegian/bokmål [nb_NO]

#7178

Translation of Trac to Finnish/suomi [fi_FI]

#7186

Translation of Trac to Argentinian Spanish/español de Argentina [es_AR]

#7353

Translation of Trac to Catalan/Català [ca_ES]

#7417

Translation of Trac to English [en_GB]

#7487

Translation of Trac into Slovene/Slovensko [sl_SI]

#7578

Translation of Trac to Estonian/eesti [et_EE]

#7918

Translation of Trac to Galician/Galego [gl_ES]

#8008

Translation of Trac to Romanian/Română [ro_RO]

This solution only requires  a simple patch. This could be an alternative in case you cannot immediately migrate to 0.12.

About message translations ... it seems it is not enough to extract messages from Genshi templates and Python source code files in order to get a fully translated user interface ... IMHO it would be nice to consider a way to include the missing messages so they can be extracted using  Babel Distutils/Setuptools Integration.