multilingual/internationalization
Alchemist
would like to make it available in more than 1 language. I read
TurboGears' documentation of multilingual/internationalization support
(see http://docs.turbogears.org/1.0/Internationalization).
Now I am interested to know whether Genshi (the latest version)
provides support for multilingual/internationalization. Any insights
on how I can make my templates appear in various languages would be
very helpful.
Thanks
Andreas Reuleaux
past (see my postings on the turbogears mailing list),
some hints though:
* you can of course pass in _() explicitely
def tr(s):... # your definition of a translation function
d['_']=tr # some dictionary d
# genshi rendering...
tmpl=loader.load(filename)
# pass in d
stream=apply(tmpl.generate, [], d)
stream.render(...)
usage in genshi templates then
<p>${_('whatever')}</p>
(some mechanism needed to determine which language you are
requesting)
That's at least what I did in some genshi only project,
i. e. not using turbogears but a simple hand written python
server instead - not sure if this applies equally easily
to turbogears, I think the rendering of the templates
is more hidden (you might have to ask on the tg mailing lists).
* according to http://docs.turbogears.org/1.0/Internationalization
(the link that you cited) i18n in tg works as follows: setting
i18n.run_template_filter to True should make your life easier:
you just write <p>whatever</p>, this is automatically converted
to <p>${_('whatever')}</p>
I did however have no good luck with this in the past (maybe some
turbogears bugs, that are corrected by now) - Some key question
here: Who is responsible for this neat trick? turbogears only (no
preparation in kid/genshi required) - this is my understanding, not
sure however - then you should find an answer on the tg(-trunk)
mailing list. Or some preparation in genshi required: then you have
to ask the tg devs what change/preparation they need exactly for
this trick to work. - Have you tried setting
i18n.run_template_filter to True with genshi templates, what
happens?
* I read something about I18N in the release notes for genshi 0.4.1
http://genshi.edgewall.org/browser/tags/0.4.1/ChangeLog
* Fix incorrect reference to translation function in the I18N filter.
* Improved I18n extraction for pluralizable messages: for any translation
function with multiple string arguments (such as ``ngettext``), a single
item with a tuple of strings is yielded, instead an item for each string
argument.
So there should be someone here on this list that has better insight
of how i18n is supposed to work
* I have some ideas about i18n in genshi/tg in general but I think
I will explain this in another posting, in short though: I am not to
convinced that Turbogears' i18n.run_template_filter is the best
solution: I think it is to much of an all or nothing approach:
either nothing is translated, or every single string in your
template is run through _(), I prefer the Zope 3 of coping with i18n
in templates: by using a separate i18n-namespace one makes clear
explicity which strings should get the attention of _(), example
<p i18n:tr="">whatever</p> or
<p i18n:tr="someid">whatever</p>
(tr is my short hand for translate)
Of course this requires some cooperation of say turbogears
and genshi people. - I am aware that this does not solve
your immediate i18n problems (I hope others can give bettter advice)
and as stated above, I hope to find some time in the future to
better explain this i18n namespace idea.
- Andreas
> !DSPAM:466eff4761254798412471!
Shannon -jj Behrens
There has been a ton of I18N-related work on this mailing list in the
past. You can check the archives for "I18N" if you want. I know
you're using TurboGears, but you may find the following helpful:
http://pylonshq.com/docs/0.9.5/internationalization.html
Best Regards,
-jj
Christopher Lenz
> * I read something about I18N in the release notes for genshi 0.4.1
> http://genshi.edgewall.org/browser/tags/0.4.1/ChangeLog
> * Fix incorrect reference to translation function in the I18N
> filter.
> * Improved I18n extraction for pluralizable messages: for any
> translation
> function with multiple string arguments (such as ``ngettext``),
> a single
> item with a tuple of strings is yielded, instead an item for
> each string
> argument.
> So there should be someone here on this list that has better insight
> of how i18n is supposed to work
Genshi 0.4 added basic infrastructure for extraction of localizable
strings from templates, and translation of those strings at runtime.
The best documentation so far is here:
<http://genshi.edgewall.org/wiki/ApiDocs/0.4.x/genshi.filters.i18n>
(it's better yet in the docs included in the source tarballs ;-) )
The approach basically equivalent to the TurboGears
run_template_filter (is that really what it's called). By default,
the text in all elements except <script> and <style> is extracted/
translated, and the same for the values of a number of attributes
(alt, title, summary, etc). You can configure which tags are ignored,
and which attributes are included.
In the development version (0.4.x and trunk), you can also use the
xml:lang attribute to flag the content of an element as not needing
localization. I.e. if you set xml:lang to a literal string such as
"en", the I18n filter will assume it should not be translated, but
instead will always be rendered in English.
> * I have some ideas about i18n in genshi/tg in general but I think
> I will explain this in another posting, in short though: I am not to
> convinced that Turbogears' i18n.run_template_filter is the best
> solution: I think it is to much of an all or nothing approach:
> either nothing is translated, or every single string in your
> template is run through _(), I prefer the Zope 3 of coping with i18n
> in templates: by using a separate i18n-namespace one makes clear
> explicity which strings should get the attention of _(), example
> <p i18n:tr="">whatever</p> or
> <p i18n:tr="someid">whatever</p>
> (tr is my short hand for translate)
> Of course this requires some cooperation of say turbogears
> and genshi people. - I am aware that this does not solve
> your immediate i18n problems (I hope others can give bettter advice)
> and as stated above, I hope to find some time in the future to
> better explain this i18n namespace idea.
I'm personally not sure why this would be preferrable. If you have
text on a page, you usually don't want to translate just parts of it
(assuming scripts and styles are ignored as they are by default).
Flagging those strings that should *not* be translated (using
xml:lang) seems a lot more convenient.
The real problem, and the one I'm not sure how to address at this
point, is translatable strings that again includes markup. Think
"this is a <a href="#">link</a>". You definitely don't want to treat
that as two separate strings, but putting the markup in the message
would require using Markup() to get it back in unescaped. I could
imagine a special i18n namespace would be helpful for such things.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/