Perché i File di Localizzazione Tradotti Rompono le App (e Cosa Deve Restare Intatto)

Un File di Localizzazione È Codice con Dentro delle Frasi

I file di lingua PO, YAML, .properties, RESX, XLIFF e JSON sembrano elenchi di frasi, ma solo i valori sono testo. Le chiavi sono identificatori che il codice cerca; i segnaposto sono spazi che il codice riempie in fase di esecuzione; gli escape e il markup sono sintassi da cui dipende il parser. Un traduttore che tratta l'intera riga come testo produrrà un file che si legge benissimo e non si carica, oppure si carica e poi va in crash la prima volta che una schermata formatta un numero. L'errore di solito compare in una sola lingua, ed è per questo che è il tipo di bug più difficile da individuare in revisione.

Cinque Cose che Devono Sopravvivere alla Traduzione Senza Modifiche

• Chiavi e nomi delle risorse — il codice cerca le stringhe tramite chiave, quindi una chiave tradotta è semplicemente una stringa mancante.
• Segnaposto — %s, %1$d, {0}, {name} e gli argomenti ICU vengono riempiti dal codice; rinominarne o eliminarne uno rompe la formattazione o genera un errore in fase di esecuzione.
• Escape e regole di codifica — un file .properties letto con il classico metodo Properties.load(InputStream) viene trattato come Latin-1, con gli altri caratteri scritti come escape \uXXXX, per cui il testo non latino grezzo può trasformarsi in mojibake.
• Markup dentro le stringhe — tag HTML, codici inline XLIFF e Markdown devono restare bilanciati, altrimenti la stringa visualizzata rompe la pagina che la circonda.
• Struttura del file — l'indentazione YAML, gli scalari a blocco, gli anchor e gli alias e l'annidamento XML sono sintassi; un rientro spostato o il nome di un anchor tradotto cambia il significato del file.

Il Plurale Non È un Singolare Più una "s"

L'inglese ha due forme plurali, quindi viene la tentazione di pensare che ogni lingua ne abbia due. Il manuale di GNU gettext mostra perché non funziona: ogni lingua dichiara la propria regola Plural-Forms, l'inglese usa nplurals=2 e il russo ha bisogno di tre forme scelte in base alle ultime cifre del numero. Un file PO tradotto in russo con solo due forme inserite viene compilato, si avvia e stampa la grammatica sbagliata per ogni quantità che termina in 2, 3 o 4. Gestire correttamente i plurali significa produrre il numero di voci msgstr richiesto dalla lingua di destinazione, non quello che la lingua di origine aveva per caso.

A Volte i Segnaposto Devono Spostarsi

L'ordine delle parole cambia da lingua a lingua, quindi una frase con due valori spesso deve disporli al contrario. I segnaposto posizionali come %1$s e %2$s, o quelli con nome come {count} e {user}, esistono proprio per questo: la traduzione può riordinarli, ma ciascuno deve comunque comparire esattamente una volta. I segnaposto anonimi, come un semplice %s, non possono essere riordinati in sicurezza: è un problema da correggere nelle stringhe di origine prima della traduzione, non dopo.

Regole di Formato da Conoscere Prima di Tradurre

Ogni formato ha i suoi punti critici. In YAML, la specifica assegna a un blocco letterale (|) e a un blocco ripiegato (>) un comportamento diverso per gli a capo, e gli anchor (&) e gli alias (*) permettono a un nodo di riutilizzarne un altro, quindi entrambi devono passare intatti. XLIFF 2.1 racchiude la formattazione originale in elementi inline come <ph> e <pc>, che la traduzione deve mantenere al loro posto attorno alle parole giuste. In .NET, le risorse RESX vengono cercate per nome in fase di esecuzione per le impostazioni cultura correnti dell'interfaccia, quindi un elemento data rinominato ripiega silenziosamente sulla lingua predefinita. E un file .properties Java tratta il primo =, : o spazio non preceduto da escape come separatore della chiave, quindi due punti vaganti in una chiave tradotta la spezzano in due.

Una Checklist di Revisione che Intercetta la Maggior Parte dei Problemi

1. Conta i segnaposto in ogni stringa di origine e di destinazione — il multinsieme deve coincidere, anche quando l'ordine non coincide.
2. Confronta le chiavi, non i valori — qualsiasi chiave presente nell'origine e mancante o rinominata nella destinazione è un bug.
3. Carica il file tradotto con il parser vero (msgfmt, un loader YAML, ResXResourceReader) prima di rilasciarlo.
4. Verifica le voci plurali rispetto alla regola della lingua di destinazione, non a quella della lingua di origine.
5. Visualizza la traduzione più lunga nell'elemento dell'interfaccia più stretto — il testo in altre lingue è spesso più lungo di quello inglese.