Come accennato nel precedente articolo Ed ecco a voi... Zikula 1.2! [4], nella versione 1.2 di Zikula è stato introdotto un nuovo sistema multilingua basato su gettext. Ma quali sono esattamente le implicazioni di questo cambiamento? Quali vantaggi (o svantaggi) porta ai traduttori e agli utenti?

Con questo articolo cerchiamo di analizzare in maniera approfondita i difetti del vecchio sistema multilingua e come l'adozione di gettext li risolve, trattando brevemente anche l'argomento compatibilità.

Il vecchio sistema: basato su define

Tutte le versioni di Zikula precedenti la 1.2 utilizzano un sistema basato sulla funzione php define [5]. Zikula ha ereditato questo sistema da PostNuke, che a sua volta lo aveva ereditato da PHP-Nuke. Il funzionamento di questo sistema è abbastanza semplice. L'autore di un modulo crea un file chiamato eng/module.php (eng sta per english) e definisce una serie di costanti PHP con la seguente sintassi:
define( '_WELCOME', 'Welcome' );
Successivamente nel codice e nei template del modulo scrive _WELCOME al posto di Welcome. Al momento di visualizzare il contenuto della pagina l'interprete PHP sostituirà tutte le occorrenze di _WELCOME con Welcome.

Per tradurre il modulo in italiano sarà sufficiente creare il file ita/module.php inserendo la traduzione:
define( '_WELCOME', 'Benvenuto' );
e quando l'utente richiederà la pagina in italiano l'interprete PHP sostituirà _WELCOME con Benvenuto.

Tutto facile no? Non proprio. Questo sistema ha infatti due grossi difetti, che negli anni ne hanno minato la reputazione e che hanno infine spinto gli sviluppatori a cercare una nuova soluzione. Analiziamo brevemente questi due difetti:

1. Quando manca la traduzione viene visualizzato il nome della costante invece che il testo originale. In altre parole se nessuno ha ancora tradotto _WELCOME in Benvenuto, invece di mostrare Welcome verrà mostrato _WELCOME. Sebbene Welcome non sia italiano è indubbiamente più elegante e comprensibile di _WELCOME.
   Purtroppo questa è una limitazione intrinseca che non può essere (efficientemente) risolta. Il problema è che in PHP non è possibile ridefinire una costante e tentare di farlo genera un errore, di conseguenza una volta letto il file contenente la versione italiana non è possibile recuperare (efficientemente) le traduzioni mancanti dalla versione inglese (includere il file originale vorrebbe dire ridichiarare tutte costanti, generando un errore fatale).
   
2. Il secondo problema è che non vi è un modo automatico per individuare velocemente quali definizioni siano state aggiunte, quali modificate e quali siano state rimosse. Il primo problema può essere attenuato dall'autore del modulo semplicemente aggiungendo le nuove voci alla fine del file. Tuttavia essendo una cosa lasciata alla discrezione del programmatore accade raramente. Il secondo e terzo caso non hanno invece una soluzione semplice. In poche parole tradurre un modulo è relativamente semplice, tenere aggiornata la traduzione è un lavoraccio.

E' evidente come questi due problemi rappresentino un limite concreto alla flessibilità del sistema, scontentando al tempo stesso sia i traduttori che gli utenti.

Il nuovo sistema: basato su gettext

Come molti di voi avranno intuito leggendo il nome gettext, la soluzione ai problemi precedentemente esposti non è stata cercata nel design di un nuovo sistema, bensì nell'adozione di alcune librerie e tool molto famosi nel mondo dell'open source. gettext [6] è infatti un utility GNU volta all'internazionalizzazione del software (spesso chiamata i18n, perchè nella parola internationalization ci sono 18 lettere tra la i e la n). Tra le altre cose gettext è alla base della traduzione del sistema operativo GNU/Linux e di innumerevoli applicativi.

Non mi dilungherò parlando nello specifico di come funziona gettext in quanto è oltre gli obiettivi di questo articolo (ed essendo un sistema molto diffuso si possono trovare in internet diverse risorse che trattano l'argomento), vediamo tuttavia come gettext risolve i due problemi che affliggono il sistema basato sui define:

1. Molto elegantemente gettext visualizza la traduzione originale nel caso quella precedente sia mancante, in quanto in questo caso non vi è alcuna limitazione tecnica. Appena tutti i moduli saranno passati a gettext il problema delle costanti non tradotte sarà solo un brutto ricordo.
   
2. Essendo gettext un progetto largamente utilizzato esistono diversi tool (per Linux, Windows e Mac) che assistono i traduttori nel loro lavoro. Questi tool individuano automaticamente le frasi mancanti, le frasi modificate e quelle rimosse. E' quindi possibile concentrarsi sulla traduzione senza preoccuparsi per la struttura del file e senza il dubbio di aver tralasciato qualche termine.

Purtroppo nel breve periodo questo nuovo sistema ha un costo non indifferente. E' infatti necessario ritradurre/riadattare tutte le traduzioni disponibili. Tuttavia i vantaggi offerti da gettext nel lungo periodo giustificano ampiamente questo sforzo, parola di traduttore!

Aggiornamento: durante la stesura dell'articolo ho dimenticato di menzionare che il nuovo sistema da un vantaggio anche allo sviluppatore. Con il vecchio metodo il programmatore si trovava a dover lavorare su più file contemporaneamente, in quanto per ogni nuova frase parola doveva prima creare la costante e poi utilizzarla nel codice. Ora invece il testo viene scritto direttamente nel codice così: __("Welcome") e una volta terminato il modulo è possibile utilizzare questo tool online [7] per "estrarre" la traduzione dal codice. Questo dettaglio automatizza la creazione dei file di traduzione, facendo perdere meno tempo al programmatore e lasciandolo libero di concentrarsi sul codice.

Compatibilità: define e gettext

La versione 1.2 di Zikula supporta entrambi i sistemi, quindi moduli "vecchio sistema" e moduli "nuovo sistema" possono coesistere senza alcun problema. E così sara in tutte le eventuali versioni 1.2.x. Tuttavia il sistema basato sui define ha le ore contate e sarà probabilmente eliminato completamente a partire da Zikula 1.3, che essendo previsto per febbraio 2010 dovrebbe garantire tempo a sufficienza per la conversione (per altro abbastanza semplice e veloce) dei moduli vecchio stile. Ma Zikula 1.3 è un'altra storia ricca di novità, e vi sarà un altro articolo in cui parlarne.

Lo staff di Zikula.