Best practice per la localizzazione del software: guida completa per sviluppatori

Scopri le migliori pratiche di localizzazione del software: prepara il codice, gestisci i contenuti dinamici e crea layout UI flessibili per i mercati globali. Guida completa con esempi e uno strumento di traduzione gratuito.

La tua app è appena stata lanciata in Francia. Il traffico è in aumento, le iscrizioni fioccano e poi la tua casella di posta viene inondata di ticket di supporto. Gli utenti non riescono a fare clic sul pulsante “Acquista ora” perché è stato tagliato. I moduli non vengono inviati. I menu di navigazione si interrompono su due righe. La tua UI, progettata con cura, sembra completamente rovinata.

Questo è ciò che accade quando si salta il processo di localizzazione del software e si passa direttamente alla traduzione. Il testo viene tradotto, ma la tua app non è stata creata per gestirlo.

Ecco come potrebbe apparire il problema:

Il motivo? Perché il tuo codice assomiglia a questo:

<button style="width: 120px">Salva modifiche</button>

<button style="width: 120px">Save Changes</button>

Questa guida ti spiega esattamente cosa fare prima di tradurre una singola stringa. Imparerai come:

• Usa file separati per i contenuti localizzabili
• Gestisci i segnaposto e i contenuti dinamici
• Prepara l’interfaccia utente per l’espansione del testo
• Carica la lingua corretta per i tuoi utenti
• Imposta le traduzioni automatiche

Alla fine, saprai come distribuire software localizzato che funzioni davvero, non solo software che è stato tradotto.

Passaggio 1: Inizia a utilizzare file separati per i contenuti localizzabili

Ecco cosa succede quando codifichi stringhe direttamente nel codice: gli strumenti di traduzione scansionano la tua base di codice alla ricerca di testo da tradurre in file di risorse come JSON, PO o YAML. Non trovano… niente. Perché non riescono a rilevare stringhe nascoste all’interno dei tuoi file JavaScript, PHP o Ruby.

Questo è l’errore più comune nella localizzazione del software. La maggior parte dei progetti di localizzazione falliti muoiono proprio qui perché i team si rendono conto troppo tardi di dover rifattorizzare migliaia di stringhe hard-coded.

Cosa conta come testo rivolto all’utente?

Tutto ciò che i tuoi utenti possono vedere:

• Etichette dell’interfaccia utente, pulsanti e voci di menu
• Messaggi di errore e testo di convalida
• Modelli di email e notifiche
• Testo di aiuto, suggerimenti e testo placeholder
• Messaggi di successo/conferma

Tutto questo deve essere inserito in file separati.

Esempio React:

// Errato - hard-coded
<button>Submit</button>

// Corretto - utilizzando react-intl
<button>{t('submit_button')}</button>

// Wrong - hard-coded
<button>Submit</button>

// Right - using react-intl
<button>{t('submit_button')}</button>

Esempio WordPress:

// Errato - hard-coded
echo 'Submit';

// Corretto - utilizzando WordPress i18n
echo __( 'Submit', 'your-textdomain' );

// Wrong - hard-coded
echo 'Submit';

// Right - using WordPress i18n
echo __( 'Submit', 'your-textdomain' );

Esempio Rails:

# Errato - hard-coded
flash[:notice] = "Profile updated successfully"

# Corretto - utilizzando Rails I18n
flash[:notice] = t('profile.update_success')

# Wrong - hard-coded
flash[:notice] = "Profile updated successfully"

# Right - using Rails I18n
flash[:notice] = t('profile.update_success')

Quale formato di file dovresti usare?

Seleziona il formato del file di risorse in base al tuo framework:

• .json – Framework JavaScript (React, Vue, Angular)
• .po/.pot – WordPress, PHP, Python (gettext)
• .yaml/.yml – Ruby on Rails
• .xml – Android (strings.xml)
• .xcstrings – iOS/macOS

Passaggio 2: Gestire correttamente segnaposto e contenuti dinamici

Quando includi dati utente nelle stringhe, come nomi, numeri o date, non utilizzare la concatenazione di stringhe.

Lingue diverse hanno ordini di parole diversi. La concatenazione interrompe questo processo dividendo le frasi in frammenti che non possono essere riordinati.

L’esempio seguente crea tre parti separate che i traduttori non possono riorganizzare. In lingue come il giapponese, dove l’ordine delle parole differisce dall’inglese, la traduzione diventa grammaticalmente scorretta.

Esempio errato (concatenazione di stringhe)

const name = 'John';
const message = 'Hello, ' + name + '!';

const name = 'John';
const message = 'Hello, ' + name + '!';

Invece, utilizza segnaposto che consentano ai traduttori di controllare l’intera frase:

Esempi corretti

msgid "Hello, %s!"
msgstr ""

msgid "Hello, %s!"
msgstr ""

{
 "greeting": "Hello, {name}!"
}

{
  "greeting": "Hello, {name}!"
}

greeting: "Hello, %{name}!"

greeting: "Hello, %{name}!"

Assicurati di utilizzare una sintassi di placeholder che funzioni con il tuo framework:

Passaggio 3: Progettare per l’espansione del testo

Ricordi quel pulsante dell’introduzione? Quello che diceva “Save” in inglese ma è stato tagliato in francese?

Questa è l’espansione del testo e non è rara. Ecco cosa ti aspetta:

• Il testo tedesco è in genere il 30% più lungo dell’inglese
• Il francese è circa il 20% più lungo
• Il cinese e il giapponese sono spesso più brevi (ma hanno altri problemi)

Queste sono medie e le singole parole possono gonfiarsi. “FAQ” diventa “Preguntas frecuentes” in spagnolo: un’espansione del 567%.

Prima di iniziare a programmare, pensa a come le diverse lingue influiscono sullo spazio durante la fase di progettazione. Utilizza modelli flessibili, in modo che i pulsanti possano crescere con il testo invece di essere tagliati. Questo consente di risparmiare tempo per il debug dei problemi di layout in seguito.

Per un approfondimento sui modelli di layout, consulta come prevenire problemi di layout con traduzioni lunghe.

Passaggio 4: Scrivere contenuti effettivamente traducibili

Il tuo stile di scrittura conta più di quanto pensi. Un inglese vago, intelligente o idiomatico può diventare un nonsenso in altre lingue.

✓ Scrivi frasi complete

Una stringa come “Nessun articolo nel carrello” potrebbe significare più cose. Non c’è un carrello? Gli articoli non sono nel carrello? Il tuo traduttore (o strumento di traduzione) deve indovinare.

Un soggetto chiaro con un verbo chiaro rende chiaro il significato, il che rende anche la stringa facile da tradurre.

Esempio corretto

"Non hai elementi salvati nel carrello."

"You have no saved items in your cart."

Questo afferma chiaramente cosa è vuoto (carrello) e cosa dovrebbe contenere (elementi salvati).

Evita i modi di dire

“This is a piece of cake” è spesso usato in inglese, ma non si traduce bene in altre lingue. Se tradotto letteralmente, i tuoi utenti tedeschi saranno molto confusi sul perché la tua app stia parlando di dessert.

Sii semplice

Non dire “eliminate” quando “remove” funziona. Non dire “utilize” quando puoi dire “use”. Le parole semplici si traducono in modo più affidabile e chiaro.

Passaggio 5: Imposta il rilevamento della lingua

Una volta che le tue stringhe sono esternalizzate e la tua UI è flessibile, devi rilevare quale lingua mostrare a ciascun utente.

La maggior parte dei framework include librerie i18n che gestiscono questo automaticamente:

• React con react-i18next

Installa react-i18next con npm, quindi configuralo per rilevare la lingua del browser e caricare i tuoi file di traduzione.

• Ruby on rails

Rails include I18n per impostazione predefinita. Configuralo in config/application.rb. Quindi, rileva la lingua dell’utente nel tuo ApplicationController.

• WordPress

WordPress gestisce automaticamente il rilevamento della lingua. Gli utenti impostano la lingua del sito in Impostazioni → Generale e WordPress carica il file .mo corrispondente da wp-content/languages/. Per i siti multilingue in cui utenti diversi necessitano di lingue diverse, è necessario un plugin come WPML per gestire la selezione della lingua per singolo utente.

Imposta una lingua di fallback

Imposta la tua lingua di fallback sulla tua lingua principale. Quando un file di traduzione non esiste o mancano delle stringhe, gli utenti vedono il fallback invece di testo interrotto o chiavi di traduzione.

Aggiungi un selettore di lingua (se necessario)

La maggior parte delle applicazioni dovrebbe rispettare automaticamente le impostazioni della lingua del browser o del dispositivo dell’utente. Ma se vuoi consentire agli utenti di sovrascriverlo manualmente, cosa comune per le applicazioni web, aggiungi un selettore di lingua e memorizza la loro scelta:

// Salva la selezione manuale della lingua dell'utente
localStorage.setItem('userLanguage', selectedLanguage);

// Controlla prima la selezione manuale, quindi utilizza l'impostazione predefinita del browser
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

// Save user's manual language selection
localStorage.setItem('userLanguage', selectedLanguage);

// Check for manual selection first, then use browser default
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Le app per dispositivi mobili in genere non includono selettori di lingua poiché gli utenti si aspettano che le app seguano le impostazioni del proprio dispositivo.

Passaggio 6: Automatizza il processo di traduzione del software

Se il tuo processo di localizzazione assomiglia a questo, stai sbagliando:

1. Esporta le stringhe in un foglio di calcolo
2. Invia il foglio di calcolo al traduttore via email
3. Attendi 3 giorni
4. Ricevi il foglio di calcolo indietro
5. Copia manualmente le traduzioni nei file JSON
6. Scopri di aver perso 12 stringhe
7. Ripeti

Questo è lento, soggetto a errori e non è scalabile.

Ecco cosa dovresti fare invece: utilizzare uno strumento di traduzione che fornisca una localizzazione continua.

PTC è uno strumento di traduzione AI che automatizza il processo di traduzione. Puoi integrarlo con il tuo repository GitHub, GitLab o Bitbucket, oppure utilizzare l’API per l’integrazione CI/CD. Quando aggiorni le stringhe, le traduzioni avvengono automaticamente.

È gratuito per 20.000 parole in 2 lingue, poi paghi solo per quello che traduci. Nessun abbonamento e per iniziare ci vogliono meno di 5 minuti.

Passaggio 7: Testa le versioni localizzate prima del lancio

Non dovresti limitarti a controllare se il testo tradotto viene visualizzato. Testa la funzionalità effettiva in ogni lingua.

• Layout: Il testo si adatta senza essere tagliato? La navigazione funziona ancora o si verifica un overflow?
• Funzionalità: I moduli vengono inviati? I messaggi di errore vengono visualizzati nella lingua giusta? La ricerca gestisce i caratteri accentati (é, ñ, ü)?
• Formattazione: Le date sono nel formato giusto (GG/MM vs MM/GG)? I numeri sono formattati correttamente (1.000,00 vs 1.000,00)? La valuta è nella posizione giusta (€100 vs 100€)?

Testa questo prima di distribuire in produzione. Scoprire che il tuo flusso di checkout tedesco è interrotto quando gli utenti iniziano a lasciare recensioni negative non è il modo in cui vuoi scoprire i bug di localizzazione.