Gestione della traduzione

File di localizzazione (Strings)

Contenuti tradotti automaticamente dall'inglese con Phrase Language AI.

I file di localizzazione sono file di testo che possono essere aperti e modificati in un editor di testo come Notepad o TextEdit o in uno dei numerosi strumenti di editing di testo avanzati utilizzati dai programmatori. Questi file seguono generalmente il principio chiave-valore. Ciò significa che contengono un elenco di frammenti di testo (stringhe) associati a ID unici (chiavi). Ogni stringa è quindi un valore di una chiave (Questo semplice esempio è il formato dei file di localizzazione utilizzati nella programmazione Java.):

  • key1 = value1

  • key2 = value2

  • ...

  • chiaveN = valoreN

Creazione di file di localizzazione

I file di localizzazione sono file di testo semplice con una struttura semplice. Possono essere creati manualmente ma di solito sono generati automaticamente da strumenti o script di internazionalizzazione disponibili per diversi ambienti di sviluppo. La creazione automatica di file di localizzazione garantisce che le strutture dei file siano valide.

Per creare un file di localizzazione, tutti i pezzi di testo visualizzabile vengono sostituiti con ID unici nei file di codice. Le stringhe di testo vengono quindi aggiunte al file di localizzazione con i loro ID.

Utilizzo dei file di localizzazione

Invece delle effettive stringhe di testo, il codice ora contiene solo chiavi. Quando il software genera una vista per l'utente, queste chiavi vengono utilizzate per cercare le stringhe associate nel file di localizzazione.

Se un'applicazione è configurata per essere utilizzata in inglese e spagnolo, tutto il testo in inglese può essere mantenuto in un file chiamato English.txt ed è la posizione predefinita del testo. Se un utente non seleziona una lingua, tutto il testo verrà estratto da questo file per generare qualsiasi visualizzazione. Se l'utente seleziona lo spagnolo, il software viene reindirizzato a Spanish.txt. Molte lingue possono essere utilizzate con un sistema come questo.

Il vantaggio è che la scelta della lingua per la visualizzazione non influisce sul codice. Se il software deve visualizzare un pulsante di accesso, potrebbe richiedere la stringa associata alla chiave login_button e ha solo bisogno di sapere in quale file cercare per recuperare la stringa appropriata per la lingua data.

Gestione delle stringhe

Come piattaforma di traduzione basata su chiavi, Phrase supporta molti diversi tipi di file di risorse. Dopo che i file sono stati caricati, le chiavi e i loro valori di stringa associati vengono estratti. Le chiavi e le stringhe vengono quindi presentate al traduttore in un formato standardizzato. I traduttori si concentrano sulla loro attività senza doversi preoccupare del formato esatto del file di localizzazione. Possono ispezionare le chiavi, perché la chiave stessa può fornire un contesto cruciale e guidarli verso le scelte di parole corrette.

Quando tutte le stringhe sono tradotte, i file vengono scaricati. Nel processo, vengono creati i formati di file di localizzazione necessari che corrispondono al file sorgente originale.

Formati di file di risorse file

Quattro ampie tipologie di risorse sono supportate e sono tutte essenzialmente basate su testo e possono essere aperte e ispezionate in un editor di testo.

Fogli di calcolo

.XLSX e .CSV sono supportati. Questi formati sono equivalenti per scopi di localizzazione e contengono righe di coppie chiave-valore. Le chiavi sono in una riga, mentre i valori corrispondenti sono in una riga adiacente. Quale colonna esatta viene utilizzata per quale scopo dipende dall'applicazione, e un localizzatore deve configurare Phrase per interpretare correttamente le colonne. I file .CSV di ZenDesk hanno una struttura fissa, quindi questo tipo di file non richiede ulteriori aggiustamenti:

"Titolo","Lingua predefinita","Testo predefinito","Testo in inglese","Stato della variante"
"simple_key","Tedesco","Chiave semplice.","Chiave semplice.","Attuale"

XML

XML è un formato che offre meta informazioni sotto forma di <tags>. La struttura del tag è utilizzata per determinare dove si trovano le chiavi e i loro valori corrispondenti, come mostrato qui da un file XML di Android:

 <string name="simple_key">Solo una chiave con un messaggio.</string>

Due formati di traduzione XML standard sono .TMX e .XLIFF. Questi non contengono solo chiavi e valori in una lingua, ma associano anche coppie di valori da una lingua sorgente con valori corrispondenti da una lingua di destinazione. Tali file sono tipicamente bilingue, come mostra questa unità di traduzione in un file Symfony Xliff:

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Solo un semplice chiave con un semplice messaggio.</source
<target xml:lang="en-GB">Solo una chiave semplice con un semplice messaggio.</target>
</trans-unit>

I programmi QT utilizzano file di risorse con una struttura molto simile a questi formati standardizzati, ma per motivi storici hanno un layout diverso.

Elenco chiave-valore semplice

Ci sono file di risorse che contengono solo elenchi semplici di chiavi e valori, come mostra questo frammento da un YAML di Ruby on Rails:

simple_key: Solo una chiave semplice con un semplice messaggio.

Molti diversi linguaggi di programmazione o piattaforme utilizzano tali formati con lievi differenze di layout.

Poiché questi sono file monolingue, un programma di localizzazione deve mantenere versioni parallele di tali file - una per la lingua sorgente e altre per le lingue di destinazione.

Gettext produce file chiave-valore contenenti informazioni aggiuntive, come commenti descrittivi o varianti plurali:

# Questa è la descrizione sorprendente per questa chiave!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Controllalo!" Questa chiave ha una descrizione! (Almeno in alcuni formati)"
msgstr[1] "Controllalo!" Questa chiave ha %s descrizioni! (Almeno in alcuni formati)"

Ci sono formati concorrenti con funzionalità e layout simili che variano in modi relativamente minori.

Array associativi

Mentre altri formati richiedono codice personalizzato (parser) per leggerli, alcuni formati sono più facili per sviluppatori e localizzatori. I formati basati su .JSON (JavaScript) e .PHP array possono essere letti e mappati direttamente in strutture di codice comuni (array) che sono facili da manipolare. Gli array possono essere complessi e diverse applicazioni generano strutture di array personalizzate.

Ad esempio, go-i18n JSON si riferisce alle chiavi come id:

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

Angular utilizza le chiavi stesse come chiavi nei suoi array:

"simple_key": "Sono una chiave semplice con un messaggio semplice.".

Poiché ci sono queste differenze minori ma cruciali, le strutture di array .JSON e .PHP ampiamente utilizzate sono supportate.

Questo articolo ti è stato utile?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.