Topic: Localizzazione, file .po, gettext

[indigo]

In fiera a FLCG 09 ho sentito un discorso sui file .po e la localizzazione tramite gettext..
incuriosito ho cercato informazioni su internet ma non son riuscito a capire quali siano i punti deboli di questo sistema e quali siano invece i punti di forza che rendono altri meccanismi più vantaggiosi..

qualcuno saprebbe darmi delucidazioni?

danke 

[Underpass]

http://en.opensuse.org/OpenSUSE_Localization_Work_with_PO_Files

[indigo]

Si, e quindi?

[Underpass]

Si traducono i messaggi nel testo. Il risultato è che il file .po - sempre da quello che ho capito - non viene letto a runtime ma deve essere compilato con il programma.

edit: un lato positivo è che forse il programma non cessa di funzionare se non vengono tradotti tutti i messaggi (ad esempio, la versione che ho compilato di VLC su Debian ha alcune voci di menu in inglese e altre in italiano).

[M@htte0]

Quindi, a spanne, i vantaggi sono un programma più reattivo, visto che la localizzazione non deve essere letta a runtime, ma una difficoltà aggiuntiva per chi avesse bisogno di cambiare localizzazione senza dover cambiare programma?

[Underpass]

Direi di sì, a occhio e croce.

http://it.wikipedia.org/wiki/Gettext

[indigo]

Ecco già questo è un punto interessante..

Ripeto, è pura curiosità.. se flod capita da queste parti, mi piacerebbe sentire anche la sua...

[M@htte0]

Direi di sì, a occhio e croce.

Quindi, a spanne

Il bello è essere tecnici, e precisi!  

[gialloporpora]

Anche WP usa i file .po per la localizzazione, il file .po va compilato ma non credo con il programma, viene compilato a parte per ottenere un file .mo per velocizzare le operazioni, credo.

Sinceramente però non so quale vantaggio (o svantaggio) possa esserci ad usare questo tipo di tecnologia.

Ciao

[Underpass]

Il bello è essere tecnici, e precisi!  

Come tutti gli informatici!

[flod]

Il vantaggio per lo sviluppatore è che molti linguaggi (ad es. php) includono in modo nativo il supporto ai file gettext. Si tratta di uno strumento molto diffuso in ambito l10n, per cui esistono diversi software per gestirlo (anche web-based): in ambito Mozilla ci sono comunità locali che convertono i file in .po, traducono e poi tornano indietro verso .dtd e .properties.

Ogni stringa è costituita da due parti: un msgid (che corrisponde alla stringa inglese) e un msgstr (stringa tradotta). Se manca la stringa tradotta è facile avere un meccanismo di fallback verso l'inglese.

Tradurre un software con i file .po è accettabile, tradurre interi siti (o manuali, come Debian) è improponibile. L'unico progetto gestito con file .po nel mondo Mozilla è AMO, peccato che i "mozilli" usino un file .po tutto loro: il msgid è un codice, non la stringa originale inglese.

Giusto per capire: http://svn.mozilla.org/addons/trunk/site/app/locale/it/LC_MESSAGES/messages.po

[indigo]

Intanto ti ringrazio per la spiegazione

Il file linkato mi sembra davvero da pazzi 

La domanda è "come mai lo stile Debian, cioè usare i file .po sulla lunga distanza, è improponibile"?

Perché è difficile testare questo tipo di localizzazioni? modificarle? perché occupano troppo spazio o impegnano troppo la macchina sulla quale girano? perché per il traduttore è uno sbattimento troppo grosso?

quale metodo preferisci/preferite?

[flod]

Per pagine di testo ha senso tradurre qualcosa che assomigli all'originale (la pagina effettiva, oppure una pagina xml con struttura simile).

Pensa di tradurre gli articoli di SUMO usando un file .po, dove ogni frase corrisponde a una singola stringa: come mantieni l'uniformità? Come segui il filo del discorso? Io stesso ho enormi problemi con AMO e quel maledetto file, ad esempio non so mai dove e in quale contesto vengono usate le stringhe che traduco

[indigo]

Ok perfetto, mi sembra un'ottima spiegazione

[prometeo]

In verità ci sono anche dei problemi "linguistici" nell'uso dei file .po che ne rendono l'uso difficile con alcune lingue, come quelle che hanno forme diverse per plurali e singolari, o con i numeri, o con maschile, femminile e neutro. E' per questo che da diversi anni Mozilla, insieme ad altri progetti OSS non meglio specificati, sta provando a sviluppare una libreria nuova che possa risolvere molti di questi problemi alla radice: il progetto Silme.
Sono stati soprattutto i sudafricani a volere fortemente una raccolta di tool per convertire tutto in .po e poi tornare indietro ai formati .dtd e .properties del mondo Mozilla (il primo formato per i file c++/java, il secondo per i Javascript), perché la loro comunità sapeva trattare solo quel tipo di file.
Ciao, Giacomo.