At first, sorry for long mail... 2007/3/10, paul <[EMAIL PROTECTED]>: > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
