Q: translation of trac into german
kama
i would like to do the translation of the pages in trac into german,
is there a good starting point e.g. Release 0.10.3 ? or may be on
0.11 ?
or the branch for 0.10/0.11 to do so?
BTW: Should i first put a ticket into trac system to reflect my
interest
in doing this job?
Can anyone give me a hint? Thanks in advance.
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung http://www.soebes.de
Dipl.Ing.(FH) Karl Heinz Marbaise email: in...@soebes.de
Tel.: +49 (0) 2405 / 415 893 ICQ#: 135949029
Emmanuel Blot
> is there a good starting point e.g. Release 0.10.3 ? or may be on
> 0.11 ?
> or the branch for 0.10/0.11 to do so?
This topic has been discussed some time ago, see for example:
http://groups.google.com/group/trac-users/msg/3ed9cfccb04fcd37
There are other interesting threads in the ML archive about Trac translation
HTH,
Manu
paul
rolling. This is not agains you or anyone but I feel trac needs
decisions on various topics to get things started.
For l10n, http://trac.edgewall.org/wiki/TracL10N seems a good start, the
various TracTerms* pages could be used for gettext...
Decisions to make:
1. use gettext for strings in python files?
2. how to handle selection of translated templates? Something like
mod_negotiation in apache with about.html, about.html.fr, about.html.de,
etc. and select the template either from Accept-Language or cookie
information. Chrome.render_template() could look for the Accept-Language
header and do a load_template() with that. Maybe add an accept_lang
field to Request()...
3. How to handle strings from the database?
thoughts?
cheers
Paul
Shun-ichi GOTO
2007/3/10, paul <pko...@gmail.com>:
> Emmanuel Blot schrieb:
> >> i would like to do the translation of the pages in trac into german,
> >> is there a good starting point e.g. Release 0.10.3 ? or may be on
> >> 0.11 ?
> >> or the branch for 0.10/0.11 to do so?
> >
> > This topic has been discussed some time ago, see for example:
> > http://groups.google.com/group/trac-users/msg/3ed9cfccb04fcd37
> >
> > There are other interesting threads in the ML archive about Trac translation
> Yes many interesting discussions but no decision how to get the ball
> rolling. This is not agains you or anyone but I feel trac needs
> decisions on various topics to get things started.
As one of proof-of-concept,
There is an implementation I have:
* localization of system resources.
* localization support of wiki contents.
I have three plugins:
* 'TracLocalizer' ... localization handler
* 'TracLocalization_ja' ... localization data provider of Japanese
* 'TracWikiNegotiator' ... content negotiation for wiki pages.
'TracLocalizer' and 'TracLocalization_ja' is not in public but
I'm using it on public site and in my office for over a year.
'TracWikiNegotiator' is in public since yesterday. This plugin is also
used in public site for several months. (old name is TracNegoWiki)
The plugin is available at:
http://trac-hacks.org/wiki/TracWikiNegotiatorPlugin
One of live site is:
- http://www.meadowy.org/~gotoh/projects/trac-wiki/
- http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=ja
- http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=en
Available languages are 'ja' and 'en'. The top page content and system
text are switchable but there is only one page to switch, sorry.
BTW, We are waiting for Trac 0.11 because when new template (genshi)
comes with 0.11, localization works for old ClearSilver would be
wasted. But I don't know when Trac 0.11 will come...
So I introduce one of personal and hacky implementation as an example.
These plugin may lose a value when trac 0.11 comes up.
So I cannot push to spread this way.
But I want to hear your opinions.
> For l10n, http://trac.edgewall.org/wiki/TracL10N seems a good start, the
> various TracTerms* pages could be used for gettext...
>
> Decisions to make:
> 1. use gettext for strings in python files?
I didn't take this strategy because gettext approach needs many changes
against original codes.
I take:
1. Make a localized ClearSilver templates
This is provided by 'TracLocalization_ja'
2. Make a data to convert HDF data replacing with regexp.
This is provided by 'TracLocalization_ja'
You can make a plugin for another language and use together.
3. Make a plugin to handle these data to localize by hooking before
rendering.
It provides:
* Nothing changed for original code, so easy to plug.
* Dynamic language selection regarding Accept-Language: in request header.
* Language oriented template selection.
* Localizable for system embedded string, not apeared in templates.
* Pluggable language resources via data provider plugin.
It has many demelits:
* This way is not 'beautiful' and 'right-way'.
* It depends on ClearSilver (HDF object).
* Cost of HDF object manipulating (using regexp)
> 2. how to handle selection of translated templates? Something like
> mod_negotiation in apache with about.html, about.html.fr, about.html.de,
> etc. and select the template either from Accept-Language or cookie
> information. Chrome.render_template() could look for the Accept-Language
> header and do a load_template() with that. Maybe add an accept_lang
> field to Request()...
I take:
* Templates are provided by data provider plugin (ex. TracLocalizer_ja)
in language subdirectory of plugin's template dir.
This subdirectory is for template selection for active language.
* Localizer decides a language from Accept-Language, and
modify template load path to allow searching localized templates.
For example, if decided language is 'ja' and standard load path is:
['/usr/share/trac/templates',
'/usr/local/myplugin/templates',
'/usr/share/templates']
Localizer add template directories from data providers at top list,
and also check each directory has 'ja' subdirectory and add it.
Then, load path would:
['/tmp/egg/TracLocalization_ja-1.0/templates/ja',
'/usr/share/trac/templates',
'/usr/local/myplugin/templates/ja',
'/usr/local/myplugin/templates',
'/usr/share/templates']
Thus, ClearSilver will find localized template before original.
* For language selection, check matching of installed localization
data providers and requested languages. Language is decided only
from existing providers. Otherwise, default 'us' language is used.
* I don't use cookie/session because it is not good to automatic
selection. When we remember language code in cookie/session, we
should provide a way to forget it. Alternatively, my plugin accept
'lang=xx' query parameter to view with specific language. It cannot
be use over session, but almost use does not need it, I though.
> 3. How to handle strings from the database?
As I described above, getting resource data from plugin.
Each language plugin can be upgraded independently.
Additionaly, wiki page contents selection implemented in 'TracWikiNegotiator'
are independent from mechanism described above.
Page localization is a simple. I choose a suffixing.
For example, for the original page 'Foo', localized page is 'Foo.ja' for
Japanese and 'Foo.fr' for French.
When we access to page 'Foo', negotiator works. Negotiator parses
Accept-Languages: header and make a list of languages. Then negotiator
search pages of "Foo.*". When suffixed page is matched to language list,
it's content is used instead of content of 'Foo'. Otherwise, use content
of 'Foo' as default (or for other languages).
When we specify 'lang=xx' parameter, language list is made from this
parameter, without using Accept-Language. It means forcing language.
When we access to 'Foo.ja', negotiation do nothing, so content of 'Foo.ja'
is used. This is needed to create/edit the localized page.
When we access to 'Foo.' as special notation, 'Foo' is used without
negotiation. This is needed to create/edit the base page.
That's all of my implementation.
TracWikiNegotiator is already in public and try to use immediately.
You can provide multi lingual site with this (maybe).
For system resource localization, my plugin is not in public
because it lacks a document what to do for localization.
And it requires actual resource data and templates translated by
someone. So it does not benefits immediately.
Bu if you want to try, it can be in public.
I'm welcome to your opinions.
# but I cannot make quick response because of my regular work...
--
Shun-ichi GOTO
Shun-ichi GOTO
> One of live site is:
> - http://www.meadowy.org/~gotoh/projects/trac-wiki/
> - http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=ja
> - http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=en
> Available languages are 'ja' and 'en'. The top page content and system
> text are switchable but there is only one page to switch, sorry.
I made French and Polish data plugin as sample, and installed there.
You can see also french and polish menu/buttons:
http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=fr
http://www.meadowy.org/~gotoh/projects/trac-wiki/?lang=po
Now four languages are available for system resources,
but page content is still only English and Japanese.
So, if you are French, you will see French menu and English content.
Templates and translated words are bollowed from TracFrenchTranslation
by eblot and TracPolishTranslation by ASI/wist.
http://trac-hacks.org/wiki/TracFrenchTranslation
http://trac-hacks.org/wiki/TracPolishTranslation
I've constructed plugins simply copying resources from these works.
# I can read nether French nor Polish :-)
--
Shun-ichi GOTO