Best practice per la localizzazione software: 10 passaggi con esempi

Questa guida ti accompagna attraverso il processo di localizzazione software dall’inizio alla fine, con best practice ed esempi di codice reali.

La tua app è appena stata lanciata in Francia. Le iscrizioni aumentano, ma poi i ticket di assistenza iniziano a inondare la tua casella di posta. Gli utenti non possono cliccare sul pulsante “Buy now” perché è tagliato. I menu di navigazione si interrompono su due righe. La tua UI, progettata con cura, appare completamente rovinata.

Questo è ciò che accade quando passi direttamente alla traduzione senza localizzare correttamente il tuo software. Il testo viene tradotto, ma l’app non è stata costruita per gestirlo.

Questa guida copre tutto ciò di cui hai bisogno per gestire correttamente la localizzazione software. Imparerai:

• Cos’è la localizzazione software
• La differenza tra localizzazione, traduzione e internazionalizzazione
• Come prepararsi al processo di localizzazione software
• Best practice per contenuti dinamici, espansione del testo, formattazione specifica per il locale e test
• Il costo della localizzazione software
• Come impostare un workflow di localizzazione che non si interrompa a ogni rilascio

Cos’è la localizzazione software?

La localizzazione software è il processo di adattamento del tuo software per un mercato specifico. Questo va oltre la semplice traduzione del testo. Significa regolare tutto ciò che influisce sul modo in cui gli utenti nel mercato di destinazione vivono il tuo software: formati di data e numero, valuta, layout della UI, immagini e riferimenti culturali.

L’obiettivo è far sì che il tuo software sembri costruito appositamente per quel mercato fin dall’inizio.

Ecco un esempio che mostra come la stessa data possa significare due cose diverse a seconda di dove si trova il tuo utente:

Questo è solo un piccolo esempio di ciò che gestisce la localizzazione software. Moltiplicalo per date, valute, formati e riferimenti culturali, e inizierai a vedere la portata del lavoro.

Localizzazione software vs. Traduzione vs. Internazionalizzazione

Molte persone usano questi tre termini in modo intercambiabile, ma significano cose diverse e avvengono in fasi diverse dello sviluppo.

Il processo di localizzazione software

La localizzazione software non è un singolo passaggio da completare prima del lancio. È un processo continuo che corre parallelamente allo sviluppo. Ecco una panoramica di come si suddivide tipicamente:

La maggior parte dei team gestisce il processo in uno di questi tre modi:

1. Waterfall La localizzazione inizia al termine dello sviluppo. Finisci di costruire, poi consegni tutto per la traduzione in un unico blocco. È semplice da gestire, ma ritarda il rilascio in altre lingue e rende costosa la correzione dei bug in quella fase.
2. Localizzazione Agile La localizzazione corre parallelamente allo sviluppo. Invece di un unico grande blocco alla fine, invii le stringhe per la traduzione durante tutto il ciclo di sviluppo. La tempistica è migliore, ma il processo è ancora manuale. Qualcuno nel tuo team deve esportare le stringhe, gestire le consegne e importare nuovamente le traduzioni.
3. Localizzazione continua La localizzazione è completamente automatizzata. Il tuo repository si connette direttamente al tuo strumento di traduzione, quindi quando una stringa cambia, viene inviata automaticamente per la traduzione. Quando la traduzione è pronta, viene unita nuovamente in modo automatico.

Best practice per la localizzazione software

Ogni progetto è diverso e le tue esigenze di localizzazione dipenderanno dal tuo stack, dai tuoi mercati di destinazione e dal tuo team. Questo elenco copre il nucleo di ciò che fa funzionare la localizzazione software.

Memorizza tutto il testo traducibile in file separati

Quando inserisci il testo direttamente nel codice sorgente (hard-coding), gli strumenti di traduzione non riescono a trovarlo. Questi strumenti funzionano scansionando file di risorse come JSON, PO o YAML alla ricerca di stringhe da tradurre. Se il tuo testo è sepolto nei tuoi file JavaScript, PHP o Ruby, la scansione risulterà vuota.

Questo è il motivo più comune per cui i progetti di localizzazione falliscono. I team scoprono il problema solo quando provano a tradurre e si rendono conto di dover rifattorizzare migliaia di stringhe.

Ecco perché è meglio spostare tutto il testo rivolto all’utente in file di risorse dedicati fin dall’inizio. Questo include tutto ciò che i tuoi utenti possono vedere:

• Etichette della UI, pulsanti e voci di menu
• Messaggi di errore e testo di validazione
• Template email e notifiche
• Testi di aiuto, tooltip e segnaposto
• Messaggi di successo e di conferma

Il formato di file da utilizzare dipende dal tuo framework:

Ecco un prima e un dopo per ogni framework principale.

React:

Prima

<button>Submit</button>

Dopo, usando react-i18next

<button>{t('submit_button')}</button>

WordPress:

Prima

echo 'Submit';

Dopo, WordPress i18n

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails:

Prima

flash[:notice] = "Profile updated successfully"

Dopo, usando Rails I18n:

flash[:notice] = t('profile.update_success')

È anche importante dare alle tue stringhe chiavi chiare e descrittive. Una chiave chiamata checkout.submit_button dice a un traduttore esattamente dove appare questa stringa e cosa fa. D’altra parte, string_147 non dice nulla, il che porta a traduzioni errate. Le chiavi descrittive rendono anche più facile per il tuo team tracciare quali stringhe sono state esternalizzate e individuare eventuali mancanze.

Usa i segnaposto per nomi, numeri e date

Quando il tuo testo include dati variabili come il nome di un utente o un numero d’ordine, si è tentati di costruire la frase unendo pezzi di testo nel codice. Questo non funziona in altre lingue.

Ecco perché:

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

Questo esempio divide la frase in tre frammenti. In inglese, l’ordine delle parole funziona. Ma in lingue come il giapponese, il nome si trova in una posizione diversa nella frase. I tuoi traduttori non possono riordinare i frammenti, quindi la frase finisce per essere grammaticalmente errata.

I segnaposto risolvono il problema mantenendo la frase intera. I tuoi traduttori o lo strumento di traduzione ricevono la frase completa su cui lavorare, incluso un marcatore che mostra dove va la variabile. Possono posizionare quel marcatore ovunque la grammatica della loro lingua lo richieda.

Ecco come appaiono i segnaposto in diversi formati di file:

JSON:

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

YAML:

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

La sintassi varia a seconda del formato, ma il principio è lo stesso.

Costruisci la tua UI per gestire testi più lunghi

La maggior parte delle lingue è più lunga dell’inglese. Un pulsante che si adatta perfettamente alla tua UI in inglese spesso risulterà tagliato in tedesco, francese o spagnolo. Se hai costruito il tuo layout basandoti su larghezze fisse, avrai una UI rovinata in ogni lingua che aggiungi.

Questi sono i tassi di espansione tipici con cui avrai a che fare:

Le singole parole possono espandersi molto più di queste medie. “FAQ” diventa “Preguntas frecuentes” in spagnolo: un aumento del 567%.

La soluzione è costruire layout flessibili invece di layout fissi. Invece di impostare una larghezza fissa su un pulsante, lascia che cresca con il suo contenuto:

Prima — la larghezza fissa si rompe nelle lingue più lunghe

button { width: 120px; }

Dopo — cresce con il testo tradotto

button {
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

Pensa a questo nella fase di progettazione. Se progetti prima per l’inglese e traduci in seguito, passerai più tempo a correggere problemi di layout in ogni lingua di quanto ne avresti speso per integrare la flessibilità fin dall’inizio.

Scrivi testi facili da tradurre

Il modo in cui scrivi il testo di origine influisce sulla qualità della traduzione. Frasi vaghe, modi di dire e giochi di parole intelligenti spesso producono traduzioni confuse o errate.

I problemi più comuni da evitare:

Frasi incomplete

Una stringa come “No items” potrebbe significare diverse cose. Non ci sono articoli nel carrello? Una ricerca non ha restituito risultati? Il tuo traduttore deve indovinare, e un’ipotesi sbagliata significa una traduzione errata.

Scrivi frasi complete con un soggetto e un verbo chiari.

Prima — ambiguo

"No items"

Dopo — significato chiaro

"You have no items in your cart."

Modi di dire

“This is a piece of cake” ha senso per un madrelingua inglese. Tradotto letteralmente in tedesco, i tuoi utenti si chiederanno perché la tua app parla di dolci. La maggior parte delle espressioni funziona solo nella lingua data, quindi è meglio evitarle del tutto.

Vocabolario complesso

Le parole semplici si traducono in modo più affidabile. Scrivi “remove” invece di “eliminate” e “use” invece di “utilize”. In caso di dubbio, scegli la parola più corta e comune.

Gestisci correttamente date, numeri e valute

I formati di data e numero variano significativamente tra i diversi locale. L’hard-coding di questi formati causa lo stesso problema dell’hard-coding del testo: funziona in un mercato e si rompe in altri.

Usa le utility di localizzazione integrate nel tuo framework per formattare questi elementi automaticamente in base al locale dell’utente.

JavaScript:

Prima

const price = '$' + amount.toFixed(2);

Dopo

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails:

Prima

"$#{price}"

Dopo

number_to_currency(price, locale: I18n.locale)

In questo modo, lo stesso codice gestisce correttamente la formattazione per ogni locale supportato.

Pianifica per il locale, non solo per la lingua

Lingua e locale non sono la stessa cosa. Lo spagnolo è una lingua. Lo spagnolo messicano (es-MX), lo spagnolo della Spagna (es-ES) e lo spagnolo argentino (es-AR) sono dei locale. Le differenze tra loro vanno oltre il vocabolario. Formati di data, valuta, riferimenti culturali e tono possono variare.

Se specifichi solo un codice lingua senza un locale, rischi di mostrare il contenuto sbagliato agli utenti in regioni specifiche.

Prendi il francese come esempio:

Quando imposti i tuoi file di risorse, usa i codici locale completi invece dei soli codici lingua. Questo ti dà la flessibilità di servire contenuti diversi a regioni diverse senza dover ristrutturare la tua configurazione in seguito.

Dai ai traduttori il contesto di cui hanno bisogno

Se decidi di lavorare con traduttori umani, tieni presente che lavorano direttamente dai tuoi file di risorse. Senza informazioni aggiuntive, tutto ciò che vedono è la stringa stessa. Non hanno modo di sapere dove appare nella UI, a cosa si riferisce o quanto spazio ha la traduzione per adattarsi.

Una stringa come “Cancel” potrebbe riferirsi all’annullamento di un ordine, di un abbonamento o dell’invio di un modulo. Ognuno di questi potrebbe tradursi diversamente a seconda della lingua.

Aggiungi commenti ai tuoi file di risorse per spiegare cosa fa ogni stringa e dove appare:

JSON con commenti di contesto

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

Se usi uno strumento di traduzione, la maggior parte delle piattaforme ti permette di allegare schermate che mostrano dove appaiono queste stringhe. Ciò consente agli strumenti di traduzione di produrre traduzioni significativamente più accurate rispetto a quando si lavora solo sul testo.

Imposta il rilevamento della lingua

Una volta che le tue stringhe sono nei file di risorse e la tua UI è flessibile, devi mostrare a ogni utente la lingua corretta automaticamente. La maggior parte dei framework gestisce questo aspetto con librerie i18n integrate.

React con react-i18next:

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails:

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

Imposta sempre una lingua di fallback. Quando un file di traduzione manca o una stringa non è stata ancora tradotta, la tua app mostra il fallback invece di una chiave rotta come auth.login_error.

Per le app web, puoi anche consentire agli utenti di ignorare manualmente la lingua rilevata. Memorizza la loro scelta in modo che persista tra le sessioni:

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Le app mobili generalmente non hanno bisogno di un selettore di lingua. Gli utenti si aspettano che le app mobili seguano le impostazioni del loro dispositivo.

Scegli uno strumento di localizzazione

Un workflow di localizzazione manuale si presenta più o meno così: esporta le stringhe in un foglio di calcolo, invialo a un traduttore, aspetta diversi giorni, ricevilo indietro, copia le traduzioni nei tuoi file, scopri che hai dimenticato 12 stringhe e ricomincia da capo. Non è scalabile.

Uno strumento di localizzazione software gestisce l’intero workflow per te. Uno valido saprà:

• Connettersi al tuo repository, rilevare stringhe nuove e modificate e mantenere le traduzioni aggiornate continuamente
• Fornire al tuo team un luogo centrale per gestire tutte le traduzioni
• Includere funzionalità CAT integrate come memoria di traduzione, rilevamento del limite di lunghezza e gestione della terminologia

PTC fa tutto questo. Inoltre, puoi tradurre le prime 20.000 parole in 2 lingue gratuitamente, e iniziare richiede meno di 5 minuti.

Scopri come PTC gestisce la localizzazione software

Testa ogni versione localizzata prima del lancio

La traduzione non è l’ultimo passaggio. Prima di distribuire una versione localizzata, testala nello stesso modo in cui testeresti qualsiasi altro rilascio.

Layout: Il testo si adatta senza essere tagliato? La navigazione funziona ancora o vedi degli overflow?

Funzionalità: I moduli vengono inviati correttamente? I messaggi di errore appaiono nella lingua corretta? La ricerca gestisce i caratteri accentati come é, ñ e ü?

Formattazione: Le date sono nel formato corretto per il locale? I numeri e le valute sono formattati correttamente? Il simbolo della valuta è nella posizione corretta?

Lingue da destra a sinistra: Se supporti l’arabo o l’ebraico, testa separatamente l’intero layout RTL. Il supporto RTL influisce su molto più della direzione del testo. Influisce sull’intero layout della tua UI.

Integra i test di localizzazione nel tuo processo di QA fin dall’inizio. Trovare un flusso di checkout interrotto in tedesco tramite le recensioni degli utenti è significativamente più costoso che individuarlo prima del lancio.

Quanto costa la localizzazione software?

Una buona localizzazione software non deve essere necessariamente costosa. Il fattore principale nel tuo budget non è il numero di lingue supportate, ma il modo in cui traduci.

La traduzione umana professionale per il software costa tipicamente tra 0,10 $ e 0,30 $ per parola. Per un’app di medie dimensioni con 15.000 parole, si parla di una cifra compresa tra 1.500 $ e 4.500 $ per lingua, prima di considerare i test, la gestione del progetto o i futuri aggiornamenti ogni volta che il tuo prodotto cambia.

La traduzione con IA con uno strumento come PTC costa una frazione di quella cifra:

Dopo la prova gratuita, PTC funziona con un modello Pay-As-You-Go. Le tue prime 500 parole ogni mese sono gratuite. Più traduci, più bassa sarà la tua tariffa per parola e, una volta raggiunta una tariffa inferiore, la manterrai per tre mesi anche se il tuo volume diminuisce.

Per ottenere una cifra esatta per il tuo progetto, usa il calcolatore di prezzi di PTC o carica direttamente il tuo file di risorse per vedere il costo prima di impegnarti.

Calcola il tuo costo di traduzione

Imposta il tuo processo di localizzazione software in 3 passaggi

Le best practice per la localizzazione software sopra descritte coprono molto terreno. Alcune, come la scrittura di testi traducibili o la pianificazione per il locale, richiedono decisioni deliberate da parte del tuo team. Ma gran parte del lavoro tecnico, come il rilevamento delle modifiche alle stringhe, la gestione dei file di traduzione, la segnalazione di problemi di lunghezza e la sincronizzazione delle traduzioni, può essere automatizzata con lo strumento giusto.

Ecco come implementare un processo di localizzazione funzionante con PTC.

Iscriviti a PTC

Crea un progetto in PTC, carica i tuoi file di risorse e seleziona le tue lingue di traduzione. Durante la prova gratuita, puoi selezionare 2 lingue.

PTC genera automaticamente una descrizione della tua app basata sul file caricato. Rivedi la descrizione e conservala o modificala. Puoi anche caricare traduzioni esistenti e aggiungere un glossario di termini che dovrebbero essere sempre tradotti in un modo specifico, come nomi di prodotti o terminologia tecnica.

L’intera configurazione richiede meno di 5 minuti.

Visualizza e perfeziona le traduzioni

Una volta che le traduzioni sono pronte, invece di modificare manualmente le singole stringhe o aggiungere membri del team per gestire le revisioni in lingue specifiche, puoi effettuare una revisione della traduzione tramite l'IA di PTC.

AI Visual QA porta il processo standard di revisione a livello di stringa un passo avanti, esaminando la tua UI reale in ogni lingua di destinazione.

Cosa smetterai di fare:

• Aprire manualmente il tuo prodotto in ogni lingua di destinazione per verificare problemi di visualizzazione
• Coordinare i revisori QA che parlano le lingue di destinazione
• Scoprire layout rotti o stringhe mancanti dopo un rilascio

Cosa otterrai invece:

• PTC revisiona visivamente la tua UI tradotta e trova problemi che l’ispezione delle stringhe non può rilevare
• I problemi trovati nelle traduzioni generate da PTC vengono corretti automaticamente
• Ogni lingua viene revisionata prima del rilascio, in pochi minuti invece di ore

Per iniziare, vai alla scheda AI Visual QA dal tuo pannello di controllo. A seconda del tipo di software che stai traducendo, potrai caricare schermate della tua UI o utilizzare l’estensione del browser PTC Visual QA per registrare le schermate per la revisione.

PTC eseguirà una scansione per individuare problemi che appaiono solo quando la tua app è in esecuzione. Corregge automaticamente i problemi a livello di traduzione, come frasi goffe, tono errato o testo che non si adatta al contesto. I problemi a livello di codice, come chiavi mancanti, stringhe hardcoded e bug di formattazione, vengono segnalati affinché il tuo team possa risolverli nel sorgente.

Connetti il tuo workflow di sviluppo

Quando avrai preso confidenza con il funzionamento di PTC, passa a Pay-As-You-Go per accedere alle funzionalità Pro, come la connessione di PTC al tuo repository GitHub, GitLab o Bitbucket. Con questa integrazione, PTC rileva automaticamente le stringhe nuove e modificate e mantiene le tue traduzioni aggiornate senza caricamenti manuali di file.

Se vuoi andare oltre, l’API di PTC ti consente di integrare la traduzione direttamente nella tua pipeline CI/CD, così le versioni localizzate sono sempre pronte per essere distribuite insieme alla tua lingua di origine.

Inizia a usare PTC gratuitamente per 30 giorni

Esempio di localizzazione software: tradurre WPML con PTC

WPML è uno dei plugin multilingue più utilizzati per WordPress. Mantenerlo tradotto in 23 lingue non è opzionale. Fa parte di ogni rilascio.

Per anni, il team lo ha fatto nel modo tradizionale: assumendo traduttori umani professionisti, gestendo file di glossario e coordinando gli aggiornamenti in tutte le lingue per ogni rilascio. Ogni volta, dovevano rispiegare da zero il prodotto, la terminologia e le aspettative. Il costo variava da 1.000 $ a 8.000 $ per rilascio.

Hanno provato alternative: crowdsourcing, workflow automatizzati e modelli ibridi. Nulla ha risolto il problema.

Da quando sono passati a PTC, i rilasci avvengono puntualmente. Le traduzioni sono complete, accurate e coerenti in tutte le 23 lingue, senza string freeze, senza costi di coordinamento e senza ritardi.

Prima di PTC

Dopo PTC

Inizia a localizzare il tuo software oggi stesso

PTC è gratuito per le tue prime 20.000 parole in 2 lingue. Iniziare richiede meno di 5 minuti.

Inizia la tua prova gratuita