Mailing List Archive: Locale support on trac

Locale support on trac

Jul 22, 2004, 10:36 PM

Post #1 of 4 (991 views)

Hi, I am new in the list, and my english isn't very good. I'm sorry and I
expect you understand me.

I'd like to see trac showing messages in other languages...

I'm from Spain and I could translate it to spanish, but trac isn't prepared.
Python have GNU gettext support: you only need to wrap the messages with the
gettext function. Here's an example of typical usage for this API:

# I think this must go in trac.cgi:
import gettext
gettext.bindtextdomain('myapplication', '/path/to/my/language/directory')
gettext.textdomain('myapplication')
_ = gettext.gettext

# Everytime you put a translatable string, you use:
print _('This is a translatable string.')

By other way, i don't know if ClearSilver have localization support, but I
could have different sets of .cs templates. And I think that's all you need to
have trac prepared to other languages!! What do you think?

Greetings,

Mario Palomo

Locale support on trac [ In reply to ]

daniel at roe

Jul 22, 2004, 10:36 PM

Post #2 of 4 (993 views)

Permalink

Mario Palomo <mario-p@iname.com> [2004-05-14/09:56]:
> I'd like to see trac showing messages in other languages [...] Python
> have GNU gettext support: [...]

It would make a lot more sense not to use the system locale, but choose
the display language based on which language(s) the browser requests in
the Accept-Language: HTTP header field, wouldn't it?

Cheers,
Dan

--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /archive/trac/attachments/20040514/820c0dd0/attachment.pgp

Re: Locale support on trac [ In reply to ]

mario-p at iname

Jul 22, 2004, 10:36 PM

Post #3 of 4 (989 views)

Permalink

Yes, you can get browser languages from the Accept-Language: HTTP header field,
and then use that language in trac.cgi. For example, if you got 'es_ES'
(Spanish from Spain) as the browser language, your first lines in trac.cgi was:

import locale
locale.setlocale(locale.LC_ALL, 'es_ES')

Of course, the 'es_ES' string was a variable name. Cheers,

Mario Palomo

Daniel Roethlisberger escribi?:
> Mario Palomo <mario-p@iname.com> [2004-05-14/09:56]:
>
>>I'd like to see trac showing messages in other languages [...] Python
>>have GNU gettext support: [...]
>
>
> It would make a lot more sense not to use the system locale, but choose
> the display language based on which language(s) the browser requests in
> the Accept-Language: HTTP header field, wouldn't it?
>
> Cheers,
> Dan
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

Locale support on trac [ In reply to ]

cmontpetit at nertec

Jul 22, 2004, 10:36 PM

Post #4 of 4 (989 views)

Permalink

Chosing the language based on the Accept-Language HTTP header is good to
pick the default language of a user but IMHO, a web app should always
offer a way to force another language. Users may be accessing the web
app from a browser that is not setup in their preferred language, or
sometimes their preferred language is set in the browser but the
translation is not good.

I like Google's way of handling languages: the default is english (since
this is their default language), but there is always a link that offers
you to select your browser preferred language.

In the context of Trac, I think a configurable application setting
should be used by default, then users could be offered to use their
browser-specified language.

Claude

>>I'd like to see trac showing messages in other languages [...] Python
>>have GNU gettext support: [...]
>
> It would make a lot more sense not to use the system locale, but choose
> the display language based on which language(s) the browser requests in
> the Accept-Language: HTTP header field, wouldn't it?