Progetti multilingua in Python (parte 1/9).

Attenzione!

Queste guide non sono più aggiornate, e in alcuni punti sono proprio superate.
Il mio libro Python in Windows tratta questi temi, e molto altro, in modo molto più completo e aggiornato. 

Cose da sapere prima di tutto.

Il supporto di Python per la traduzione multi-lingua del codice, specialmente in ambiente Windows, è… un po’ ruvido. A peggiorare le cose, le guide e gli articoli che si trovano in giro sono spesso approssimativi e quasi sempre pensati per il mondo Linux. Chi scrive ha messo da parte nel tempo un po’ di appunti, trucchi e scorciatoie: raccogliamo le cose essenziali da sapere. Questa non è una guida completa, ma può essere un buon punto di partenza. La piattaforma di riferimento è Windows, ma in pratica il 95% di quello che diremo vale dappertutto.
Riassumiamo in breve gli aspetti preliminari che dovreste già conoscere, almeno in linea generale.

Internazionalizzazione e localizzazione.

Sono due concetti diversi. La “localizzazione” (localization, in breve l10n) riguarda gli adattamenti che un programma deve fare per adeguarsi alle convenzioni in uso nel “locale” dell’utente. La l10n riguarda aspetti diversi, dal modo in cui si scrivono i numeri (i separatori decimali e i raggruppamenti delle cifre), a quello in cui si scrivono le date, alle convenzioni per i valori monetari. Il supporto di Python per la l10n è nel modulo locale della libreria standard. Potete dare un’occhiata alla documentazione per farvi un’idea del problema (e delle soluzioni). Questa guida non riguarda la l10n: tuttavia dovremo tornare sul modulo locale perché ci sono dei dettagli importanti anche per noi.
La “internazionalizzazione” (internationalization, in breve i18n) riguarda in modo specifico la traduzione del codice (almeno per le parti che devono essere visibili per l’utente finale) in lingue differenti. Il supporto di Python per la i18n è nel modulo gettext della libreria standard, che offre in buona sostanza i meccanismi per selezionare la “lingua corrente” e tradurre di conseguenza quel che c’è da tradurre in modo trasparente.
Un programma potrebbe quindi essere “localizzato” ma non “tradotto”, o viceversa. È una scelta vostra, se fornire o meno il supporto per questi aspetti. Non fatevi ingannare dall’uso generico del termine “localizzato”, in Italiano, per dire “tradotto”. In questa guida useremo sempre i termini più specifici.

Che cosa tradurre, che cosa no.

In breve: dovete tradurre tutto quello che l’utente finale dovrà vedere, ma non una riga di più. Se il vostro programma ha un’interfaccia grafica (una GUI), traducete le etichette dei pulsanti e dei menu, per esempio.
Non traducete le docstring, non traducete i messaggi che finiscono nei log, non traducete i messaggi delle eccezioni (cose del tipo: raise MyException('something went wrong!'), etc.). Se scrivete una libreria di backend, in genere non dovete tradurre nulla.
In ogni caso, tenete presente che marcare una stringa per la traduzione è una cosa diversa da tradurla (vedremo presto questo nel dettaglio). Non siete obbligati a tradurre concretamente, ma è utile predisporre comunque il meccanismo di traduzione nell’eventualità che in futuro qualcuno (magari voi stessi) abbia voglia di mettersi effettivamente a tradurre. Aggiungere una traduzione a cose fatte è molto semplice. D’altra parte è lungo e noioso modificare il codice per inserire i meccanismi per la traduzione, una volta che il progetto è finito.