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"?