#280 closed enhancement (fixed)
Add support for internationalization of templates
Reported by: | 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@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
Add support for multilingual templates
Attachments (0)
Change History (31)
comment:1 by , 21 years ago
comment:3 by , 19 years ago
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 by , 19 years ago
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 by , 19 years ago
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 by , 19 years ago
Cc: | added |
---|
comment:7 by , 19 years ago
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 by , 19 years ago
(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 by , 19 years ago
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 by , 19 years ago
Cc: | added |
---|---|
Keywords: | L10N added |
comment:11 by , 19 years ago
Milestone: | 2.0 → 0.11 |
---|
comment:12 by , 19 years ago
Cc: | added |
---|
comment:13 by , 19 years ago
Cc: | added |
---|
comment:16 by , 18 years ago
Cc: | added |
---|
comment:17 by , 18 years ago
Cc: | added |
---|
comment:18 by , 18 years ago
Is there any way how non-Python programmer can help with this ticket? This is a really blocker for using Trac by our customers.
follow-up: 21 comment:19 by , 18 years ago
Description: | modified (diff) |
---|---|
Keywords: | I18N added |
Milestone: | 0.11 → 0.12 |
Severity: | normal → major |
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.
follow-up: 22 comment:20 by , 18 years ago
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 by , 18 years ago
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.
follow-up: 31 comment:22 by , 18 years ago
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 by , 18 years ago
Cc: | 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:25 by , 17 years ago
Cc: | added |
---|
comment:26 by , 17 years ago
Cc: | added |
---|
comment:28 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Trunk now has support for L10N.
comment:29 by , 16 years ago
Milestone: | 0.13 → 0.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 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 by , 16 years ago
Cc: | 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.
That will be great !!