Progetti multilingua in Python (parte 4/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. 

Produrre i cataloghi .po per i traduttori.

Questa è la parte più semplice, almeno per voi. I file per i traduttori sono delle copie del template .pot. Per convenzione, dovreste cambiare la loro estensione in .po, conservando il nome identico. Forse vi conviene temporaneamente scegliere l’estensione .po.txt, se i vostri traduttori non sono esperti. In ogni caso, quando il traduttore vi riconsegna il file tradotto, cambiate l’estensione in .po.
Il traduttore dovrebbe compilare i metadati di sua competenza, e soprattutto tradurre, si capisce. Da parte vostra, dovete fare attenzione che i traduttori rispettino le parentesi di interpolazione nelle stringhe, riportandole anche nelle traduzioni.

Compilare i cataloghi (da .po a .mo).

Per essere utilizzabili da gettext, i cataloghi .po devono essere compilati in un formato binario. Python dispone di uno script adatto allo scopo:

> py "C:/Program Files/Python36/Tools/i18n/msgfmt.py" myapp.po

Lo script msgfmt.py produce un catalogo compilato con estensione .mo: nel nostro caso, myapp.mo. Ripetete l’operazione per ciascun catalogo, nelle varie lingue (attenzione a non confondervi, visto che hanno tutti lo stesso nome!).
Dove devono stare questi cataloghi compilati (che, ripetiamo: hanno tutti lo stesso nome)? Per convenzione, stanno in una directory locale che ha una struttura interna ben precisa. Supponiamo che la nostra applicazione sia (per il momento) tradotta in due lingue: inglese e francese. Allora la directory locale ha questa struttura:

locale 
      |- en
      |    |- LC_MESSAGES
      |                  |- myapp.mo, myapp.po
      |
      |- fr
           |- LC_MESSAGES
                         |- myapp.mo, myapp.po

In sostanza, dentro locale c’è una directory per ciascuna lingua (indicata con il consueto codice a due lettere). Dentro la directory della lingua, c’è solo una directory LC_MESSAGES, e dentro questa vive il nostro catalogo compilato myapp.mo. Per convenienza, potete conservare lì anche il catalogo non compilato myapp.po, ma a gettext non serve. Fin quando sviluppate il codice, va bene così; quando in futuro vorrete distribuirlo, toglierete i file .po lasciando solo i cataloghi compilati.
E la directory locale, dove deve stare? Qui c’è un intoppo. Nel mondo Linux, la consuetudine è avere una locale unica, centralizzata, dentro cui vivono i cataloghi di molti programmi: per questo è importante che i cataloghi abbiano un nome univoco (un “dominio”, come abbiamo visto). Dentro locale/en/LC_MESSAGES, per esempio, potete trovare molti cataloghi oltre a quello della vostra applicazione. In Windows però questa consuetudine non esiste. Potete mettere locale nella directory/package principale della vostra applicazione, o anche un livello più su, se preferite mantenere solo il codice Python dentro la directory/package:

myapp
     |- myapp
     |       |- (e qui tutti i moduli Python)
     |- locale
              |- (e qui tutti i cataloghi)

Se volete sviluppare in modo cross-platform, avete un piccolo problema di distribuzione: in Windows potete mantenere locale “vicina” all’applicazione, ma in Linux dovreste mettere i cataloghi nella directory centralizzata. Il problema è che questa directory varia a seconda delle diverse distribuzioni. Il punto è che comunque potete dire a Python di cercare le traduzioni in una directory specifica, come vedremo (e in Windows è senz’altro necessario): potete seguire lo schema di Windows anche su Linux, se non volete starci troppo a pensare. Del resto, molte applicazioni cross-platform in Linux fanno proprio questo, tenendosi “vicini” i propri cataloghi senza cercare di indovinare caso per caso dov’è la directory centralizzata.
Una volta predisposta la directory locale e compilati i cataloghi .mo, siamo pronti per attivare il meccanismo di gettext nel nostro programma Python. Prima di vedere come si fa, conviene adesso aprire una parentesi su qualche strumento più avanzato rispetto ai rudimentali script pygettext.py e msgfmt.py che abbiamo usato finora.