Edgewall Software
Modify

Opened 14 years ago

Closed 10 years ago

Last modified 9 years ago

#280 closed enhancement (fixed)

Add support for internationalization of templates

Reported by: king@… Owned by: Jeroen Ruigrok van der Werven
Priority: normal Milestone: 0.12
Component: general Version: 0.6.1
Severity: major Keywords: I18N L10N
Cc: m@…, filhocf@…, progfou@…, anarcat@…, d-sleeman@…, durchanek@…, axo@…, felix.schwarz@…, lustin@…, olemis@…
Release Notes:
API Changes:

Description (last modified by Christian Boos)

Add support for multilingual templates

Attachments (0)

Change History (31)

comment:1 Changed 14 years ago by jimmy_lee14@…

That will be great !!

comment:2 Changed 14 years ago by daniel

Milestone: 2.0

This is definitely a post-1.0 feature.

comment:3 Changed 13 years ago by Matthew Good

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.

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by Emmanuel Blot

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 ?

comment:6 Changed 13 years ago by anonymous

Cc: vyt@… added

comment:7 Changed 13 years ago by Emmanuel Blot

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…)

comment:8 Changed 13 years ago by Christian Boos

(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:

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

comment:9 Changed 13 years ago by Emmanuel Blot

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.

comment:10 Changed 12 years ago by Markus Tacker <m@…>

Cc: m@… added
Keywords: L10N added

comment:11 Changed 12 years ago by Christopher Lenz

Milestone: 2.00.11

comment:12 Changed 12 years ago by Claudio Filho <filhocf@…>

Cc: filhocf@… added

comment:13 Changed 12 years ago by anonymous

Cc: progfou@… added

comment:14 Changed 12 years ago by anonymous

Its ready ?

comment:15 Changed 12 years ago by Emmanuel Blot

It's ready ?

Check out the milestone: 0.11

comment:16 Changed 12 years ago by anonymous

Cc: anarcat@… added

comment:17 Changed 12 years ago by anonymous

Cc: d-sleeman@… added

comment:18 Changed 11 years ago by 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.

comment:19 Changed 11 years ago by Christian Boos

Description: modified (diff)
Keywords: I18N added
Milestone: 0.110.12
Severity: normalmajor

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.

comment:20 Changed 11 years ago by 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?

comment:21 in reply to:  19 Changed 11 years ago by Emmanuel Blot

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.

comment:22 in reply to:  20 ; Changed 11 years ago by Emmanuel Blot

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.

comment:23 Changed 11 years ago by durchanek@…

Cc: durchanek@… added

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 ;-)

comment:24 Changed 11 years ago by axo@…

Cc: axo@… added

registering for notification

comment:25 Changed 11 years ago by anonymous

Cc: felix.schwarz@… added

comment:26 Changed 10 years ago by anonymous

Cc: lustin@… added

comment:27 Changed 10 years ago by anonymous

Cc: vyt@… removed

Unsubscribed from this ticket

comment:28 Changed 10 years ago by Jeroen Ruigrok van der Werven

Owner: changed from Jonas Borgström to Jeroen Ruigrok van der Werven
Status: newassigned

Trunk now has support for L10N.

comment:29 Changed 10 years ago by Christian Boos

Milestone: 0.130.12

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

comment:30 Changed 10 years ago by Jeroen Ruigrok van der Werven

Resolution: fixed
Status: assignedclosed

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.

comment:31 in reply to:  22 Changed 9 years ago by olemis@…

Cc: olemis@… added

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 :

No results

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jeroen Ruigrok van der Werven.
The resolution will be deleted.
to The owner will be changed from Jeroen Ruigrok van der Werven to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.