Esistono diverse tecniche per costruire i file po al fine di internazionalizzare un prodotto esistente:

• farlo a mano;
• utilizzare i18ndude;
• utilizzare PlacelessTranslationService (strada scelta per MailmanSubForm).

La prima strada è quella da escludere subito a priori, a meno che non si debbano fare delle piccole modifiche a file po esistenti. Vediamo cosa comporta invece adottare le altre due opzioni...

NB: è uscita una guida più recente che parla di i18ndude: link. Questo articolo potrebbe contenere informazioni non aggiornate!

i18ndude

i18ndude è un prodotto per Plone che permette di estrarre informazioni sull'internazionalizzazione di page template esistenti, costruendo automaticamente file po. Inoltre consente di trovare elementi senza traduzioni, fare il merging e sincronizzare file po.

E' un approccio molto valido, come mostrato nella seguente guida.

Problemi

In passato, con le prime versioni di i18ndude, si erano verificati alcuni problemi:

• errori nel parsing delle page template di un prodotto;
• estrazione delle informazioni unicamente per le sole page template, ma non per i msgid specificati nello schema dei propri ArcheType.

Ora, invece, i18ndude è in grado di estrarre correttamente le informazioni da tradurre da:

• page template;
• ZCML file;
• moduli Python.

In definitiva, l'uso di i18ndude è consigliato.

PlacelessTranslationService

Utilizzare il PlacelessTranslationService di Plone comporta l'applicazione di un semplice trucchetto consistente in pochi passi:

• creare nella cartella i18n del prodotto da tradurre un file po vuoto (contenente solo l'intestazione specificando la lingua), ad esempio: MailmanSubForm-it.po;
• copiare MailmanSubForm-it.po e creare un file uguale, ma con estensione .missing (esempio: MailmanSubForm-it.missing);
• riavviare Zope;
• visitare le pagine che si vogliono tradurre.

In questo modo il servizio di traduzioni di Plone andrà a riempire il file con estensione .missing con tutte le entry i18n di cui non ha trovato una traduzione, permettendo così il facile recupero dei msgid delle label e delle description definite nei field Archetype degli oggetti che sfuggivano ad i18ndude.

Problemi

Questa tecnica funziona molto bene, nonostante l'approccio estremamente semplice ed anche un po'... grezzo.

Esiste tuttavia un problema: nel file .missing vengono inserite solo le entry i18n effettivamente renderizzate. Ciò significa che se alcune sezioni appaiono solo in certe determinate condizioni (magari a causa di un tal:condition), possono non essere registrate nel file .missing se la condizione non è specificata.

Conclusioni

Sicuramente l'approccio combinato delle tecniche i18ndude e PlacelessTranslationService costituisce la via migliore e più veloce sia per tradurre un prodotto che per costruire e gestire nel tempo i file po per l'internazionalizzazione.

Infatti, utilizzando entrambe le tecniche si è relativamente sicuri di non aver omesso delle entry da tradurre nei file po, e soprattutto è possibile internazionalizzare interi prodotti senza supporto i18n, con un piccolo dispendio di tempo.

Aggiornamento

All'epoca della scrittura di questa guida i18ndude dava qualche problema. Ora invece riesce molto bene ad estrapolare tutte le informazioni da moduli Python, file ZCML e page template. Inoltre mette a disposizione delle comode funzionalità per gestire i merging tra i file po.

Allo stato attuale delle cose, si ritiene che la strada migliore da seguire sia sicuramente quella che prevede l'utilizzo di  i18ndude!