On Fri, Jan 09, 2009 at 12:24:02AM +0100, Pietro Battiston wrote:
> Il giorno gio, 08/01/2009 alle 23.38 +0100, Alessandro Dentella ha
> scritto:
> > eseguo (senza cartella locale e senza file .po/.mo)::
> >
> > san...@bluff:/tmp$ LANG='it_IT' python test.py
> > Hello World
> >
> > san...@bluff:/tmp$ LANG='fr_FR' python test.py
> > Traceback (most recent call last):
> > File "test.py", line 2, in <module>
> > t = gettext.translation('example', 'locale')
> > File "/usr/lib/python2.5/gettext.py", line 484, in translation
> > raise IOError(ENOENT, 'No translation file found for domain', domain)
> > IOError: [Errno 2] No translation file found for domain: 'example'
> >
> >
> > La versione con 'bindtextdomain' invece funziona anche cambiando LANG.
> >
> > Cosa sbaglio?
> > La traduzione non c'è neanche per it_IT...
> >
> > suggerimenti?
> >
>
> Se la traduzione non c'è, le stringhe vengono mostrate in inglese, ma se
in realtà viene mostrato il msgid, che non è necessariamente in inglese né
un fallback
> la locale non è proprio configurata la libreria locale di python si
> arrabbia (penso che questo succederà con qualsiasi programma python,
> mentre un programma C userebbe "the fallback 'C' locale.").
Non è così. Se uso l'esempio con bindtextdomain:
import gettext
gettext.bindtextdomain('myapplication', 'locale')
gettext.textdomain('myapplication')
_ = gettext.gettext
# ...
print _('This is a translatable string.')
tutto funziona (mi ritorna il msgid) anche se manca il locale. La prima
versione, quella con class-based gettext non mi funziona ad esempio in un XP
fresco di instalazione tutto in italiano: lì non è impostata la variabile
LANG.
> "locale -a" ti dà la lista delle locale configurate nel sistema, ovvero
> che puoi utilizzare (a prescindere dall'avere o meno le stringhe di un
> dato programma); per installarne altre i pacchetti debian sono della
> forma language-pack-xy-base, es. language-pack-fr-base
ma io sto scrivendo un modulo che può essere usato nei più diversi sistemi,
non posso adottare una soluzione che appena uno ha un locale sballato mi da
errore...
doctest
-------
Possibile che la soluzione *preferita* dalla documentazione sia di fatto la
più delicata? in particolare usando i doctest ottengo sempre l'errore sopra
riportato se uso la versione class-based, anche se impongo un LANG
supportato dal mio sistema (>>> os.environ['LANG'] = 'en_US.utf8')
babel
------
L'ultimo capitolo di questa battaglia per la localizzazione è babel. Lo uso
per la localizzazione di numeri e date e va egregiamente ma nuovamente vuole
assolutamente che sia impostato un locale e non passa ad un default
'c'. Anzi usando LANG=C da errore dicendo che non è riconosciuto.
Potrei bypassare il problema testando la variabile prima ed impostandola
ad un default ragionevole (en_US) ma mi accorgo che i sistemi windows (almeno
il mio XP virtuale) non usa queste variabili... come faccio a capire che
localizzazione è in uso?
sandro
*:-)
PS: la mailing list di babel sembra una stanza anaecoica...
--
Sandro Dentella *:-)
http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
