Tradotto con l’IA di Lara Translate
Se lanci la tua app in una sola lingua, lasci fuori degli utenti. Però è risaputo che i processi di localizzazione delle app sono facili da sbagliare — soprattutto quando sviluppatori e traduttori usano strumenti e formati diversi e lavorano in fusi orari differenti. XLIFF esiste proprio per colmare questa lacuna. È il formato XML che iOS, Angular e Symfony generano quando estrai le stringhe da tradurre, e quello che si aspettano di ricevere dopo la traduzione. Se segui il flusso di lavoro giusto, la localizzazione diventa un processo ripetibile e scalabile. Se sbagli, ogni ciclo di rilascio si interrompe.
|
TL;DR
|
Risposta breve
Per localizzare un’app mobile o web usando XLIFF: esporta le stringhe dal tuo framework in formato .xliff o .xlf, traduci il file con uno strumento che preservi la struttura XML e i tag inline, poi reimporta il file tradotto e compila per ogni locale di destinazione. Lara Translate gestisce la fase di traduzione con il supporto completo per XLIFF 1.2 e 2.0 ed è compatibile con Xcode, Angular e Symfony fin da subito.
Perché è importante: XLIFF è il formato di scambio per la traduzione utilizzato dai framework per app più diffusi. Quando il flusso di lavoro funziona, la localizzazione è una parte prevedibile e senza interruzioni del ciclo di rilascio. Quando non funziona — a causa di tag danneggiati, versioni di file incompatibili o glossari mancanti — l’unica soluzione è ricompilare dal file di origine, il che richiede tempo e ritarda il lancio.
Traduci all’istante le stringhe XLIFF della tua app
Carica il file .xliff esportato da Xcode, Angular o Symfony. Lara lo traduce preservando completamente i tag e gli ID — pronto per essere reimportato direttamente nel tuo build.
Perché XLIFF è lo standard per la localizzazione delle app
Le stringhe delle app non sono solo testo. Contengono placeholder per valori dinamici (nome utente, prezzo, numero), hanno limiti di caratteri imposti dai vincoli dell’interfaccia utente e forniscono informazioni sul contesto in cui appaiono nell’interfaccia. XLIFF è stato progettato per contenere tutto questo, oltre al testo traducibile stesso.
Ecco perché è diventato il formato predefinito per i principali framework di sviluppo di app:
- iOS / macOS (Xcode): i riferimenti
NSLocalizedStringnel tuo codice vengono esportati in un unico file .xliff tramite la funzione “Export for Localization” di Xcode. Dopo la traduzione, importalo di nuovo e Xcode distribuirà le stringhe nei file .strings corretti in base alla locale. - Angular: eseguendo
ng extract-i18n, si genera un file XLIFF 1.2 (o 2.0) che contiene tutte le stringhe i18n contrassegnate nei tuoi template. Le versioni tradotte vengono compilate in fase di build tramite la configurazione della locale in angular.json. - Symfony (PHP): XLIFF è uno dei formati nativi dei cataloghi di traduzione di Symfony, la scelta consigliata per i progetti che coinvolgono traduttori esterni o flussi di lavoro con CAT tool.
- Android: Android usa nativamente strings.xml, ma molti team lo convertono in XLIFF per la fase di traduzione per sfruttare la compatibilità con i CAT tool, poi lo riconvertono.
Il flusso di lavoro per la localizzazione di app con XLIFF
Passo 1: Estrai le stringhe dal tuo codebase
Per iOS, l’opzione “Export for Localization” di Xcode genera un file .xliff con tutte le stringhe localizzabili organizzate per file di origine. Per Angular, ng extract-i18n --output-path src/locale genera il file. Per Symfony, usa il comando translation:extract.
Passo 2: Traduci il file XLIFF
È qui che i team di solito commettono un errore: inviano via e-mail il file .xliff a un traduttore freelance che lo apre in un editor di testo, oppure lo elaborano con uno strumento di traduzione generico. Il risultato prevedibile sono placeholder danneggiati e XML non valido.
L’approccio corretto: usa uno strumento che comprenda la struttura XML di XLIFF. Lara elabora il file correttamente, traduce solo il testo leggibile all’interno degli elementi <source> e produce un file XLIFF valido e importabile.
Passo 3: Controlla e verifica
Prima di importare, assicurati che tutti i tag inline siano intatti, che gli ID delle trans-unit corrispondano a quelli originali e che le stringhe tradotte non siano troppo lunghe per la tua interfaccia utente. La memoria di traduzione e il glossario di Lara mantengono la coerenza terminologica in tutte le versioni dell’app.
Passo 4: Reimporta il file XLIFF tradotto
In Xcode, usa “Import Localizations”. In Angular, metti il file XLIFF specifico per la locale in src/locale e indicane il percorso in angular.json. In Symfony, inserisci il file tradotto in translations/.
Passo 5: Compila e testa per ogni locale
Esegui una compilazione per ogni locale di destinazione. Controlla se ci sono problemi di overflow del testo, troncamento, rendering dei placeholder e layout da destra a sinistra per l’arabo, l’ebraico e il persiano.
Errori comuni di localizzazione XLIFF nello sviluppo di app
Usare un editor di testo per la traduzione. Aprire un file XLIFF in VS Code e modificare direttamente le stringhe di origine è un modo sicuro per creare errori di codifica XML, tag di placeholder non funzionanti e modifiche accidentali agli ID. Per l’XLIFF serve un editor strutturato.
Inviare la versione sbagliata del file. Se il tuo progetto usa XLIFF 2.0 ma lo strumento CAT del tuo traduttore supporta solo la versione 1.2 (o viceversa), il file viene importato in modo errato o non viene importato affatto. Lara gestisce entrambe le versioni, quindi questo problema non si verifica.
Non usare un glossario. Le stringhe dell’app contengono nomi di prodotti, etichette di funzionalità e termini dell’interfaccia utente che devono essere coerenti in tutte le versioni e in tutte le lingue. Il glossario di Lara applica automaticamente queste regole a ogni traduzione XLIFF.
Stringhe senza contesto. “Back” potrebbe essere un pulsante di navigazione, un’etichetta direzionale o l’interfaccia per la restituzione di un prodotto. Senza contesto, i traduttori sbagliano. Aggiungi note agli elementi <trans-unit> prima di inviarli per la traduzione.
Scalare la localizzazione XLIFF tra le varie versioni
Grazie alla memoria di traduzione di Lara, le stringhe tradotte nella versione 1.0 non vengono ritradotte nella versione 1.1 — il sistema le riconosce e applica automaticamente la traduzione approvata. Il caricamento in blocco ti permette di elaborare file XLIFF per tutte le lingue di destinazione in un’unica sessione. Per i team aziendali, l’opzione di revisione umana di Lara offre una convalida bilingue esperta per le stringhe più importanti prima del rilascio.
Localizza la tua app senza i grattacapi dell’XLIFF
Lara traduce i file XLIFF esportati da Xcode, Angular e Symfony — mantenendo intatti ogni tag, ID e placeholder. La memoria di traduzione mantiene la coerenza tra le versioni. Non serve la carta di credito.
FAQ
Xcode accetta i file XLIFF tradotti con Lara?
Sì. Lara mantiene la struttura XLIFF prevista da Xcode, compresi gli ID delle trans-unit che rimandano ai tuoi file .strings e i tag inline per gli specificatori di formato. Importa il file tradotto direttamente dal menu “Import Localizations” di Xcode.
Lara supporta il formato XLIFF generato dagli strumenti i18n di Angular?
Sì. ng extract-i18n genera XLIFF 1.2 o 2.0, a seconda della tua configurazione. Sono supportate entrambe le versioni. Dopo la traduzione, il file di output va direttamente in src/locale e viene referenziato nella configurazione di build di Angular.
Come faccio a proteggere i nomi dei marchi e i termini intraducibili?
Crea un glossario in Lara prima di eseguire la traduzione. Il glossario dice a Lara di lasciare intatte quelle stringhe in ogni file XLIFF che elabora. Puoi anche contrassegnare singoli elementi <trans-unit> con translate="no" nel file di origine — Lara rispetta questo attributo.
Lara riesce a gestire un file XLIFF grande con centinaia di trans-unit?
Sì. Lara supporta file di grandi dimensioni e caricamenti in blocco. Per un’app in produzione con migliaia di stringhe in più locale, l’elaborazione in blocco ti consente di tradurre tutti i file XLIFF nella lingua di destinazione in un’unica sessione.
Posso usare Lara insieme a un CAT tool come Trados o memoQ?
Sì. Usa Lara per pre-tradurre file XLIFF su larga scala e poi invia l’output a uno strumento CAT per la revisione — il meglio della traduzione automatica e della supervisione umana nella stessa pipeline.
Questo articolo tratta di
- Spiegare perché XLIFF è il formato di localizzazione nativo per lo sviluppo di app iOS, Angular e Symfony e cosa lo distingue dai formati di documento.
- Illustrare l’intero flusso di lavoro per la localizzazione di app in XLIFF: estrazione delle stringhe, traduzione, convalida, reimportazione e compilazione per locale.
- Identificare gli errori più comuni che i team commettono quando traducono i file XLIFF delle app e come evitarli.
- Mostrare in che modo la memoria di traduzione, i glossari e l’elaborazione in blocco rendono la localizzazione XLIFF scalabile nei vari cicli di rilascio.
- Aiutare gli sviluppatori a scegliere l’approccio di traduzione giusto in base al framework della loro app e alle dimensioni del team.
Localizza la tua app con XLIFF
Carica il file .xliff della tua app su laratranslate.com/translate-xliff e ottieni una traduzione rispettosa dei tag e pronta per l’importazione per ogni locale di destinazione.
Anche in questa serie:
