Best practice per la localizzazione software: 10 passaggi con esempi

Questa guida ti accompagna nel processo di localizzazione del 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 riescono a cliccare sul pulsante “Acquista ora” perché è tagliato. I menu di navigazione si interrompono su due righe. La tua interfaccia utente, progettata con cura, sembra 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 localizzare correttamente il software. Imparerai:

Cos’è la localizzazione del software?

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

L’obiettivo è far sì che il tuo software sembri costruito 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 l’utente:

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

Localizzazione del 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 del software

La localizzazione del 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. I tempi sono migliori, ma il processo è ancora manuale. Qualcuno nel tuo team deve esportare le stringhe, gestire le consegne e importare 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 alla traduzione. Quando la traduzione è pronta, viene reintegrata automaticamente.

Best practice per la localizzazione del software

Ogni progetto è diverso e le tue esigenze di localizzazione dipenderanno dal tuo stack, dai tuoi mercati di riferimento e dal tuo team. Questo elenco copre i punti fondamentali per far funzionare la localizzazione del software.

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 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 prima.

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 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 e di conferma

Il formato di file da utilizzare dipende dal tuo framework:

Ecco un prima e dopo per ogni framework principale.

React:

<button>Submit</button>

<button>Submit</button>

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

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

WordPress:

echo 'Submit';

echo 'Submit';

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

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

Ruby on Rails:

flash[:notice] = "Profile updated successfully"

flash[:notice] = "Profile updated successfully"

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

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

È anche importante dare alle 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.

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 + '!';

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 placeholder 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 placeholder in diversi formati di file:

JSON:

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

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

YAML:

greeting: "Hello, %{name}!"

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

msgid "Hello, %s!"

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

La maggior parte delle lingue è più lunga dell’inglese. Un pulsante che si adatta perfettamente alla tua interfaccia utente in inglese spesso verrà tagliato in tedesco, francese o spagnolo. Se hai costruito il tuo layout basandoti su larghezze fisse, avrai un’interfaccia utente 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 quelli fissi. Invece di impostare una larghezza fissa su un pulsante, lascia che cresca con il suo contenuto:

button { width: 120px; }

button { width: 120px; }

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

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

Pensaci già in fase di progettazione. Se progetti prima per l’inglese e traduci dopo, passerai più tempo a correggere i problemi di layout in ogni lingua di quanto ne avresti impiegato per costruire la flessibilità fin dall’inizio.

Il modo in cui scrivi il testo originale 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 “Nessun articolo” 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.

"No items"

"No items"

"You have no items in your cart."

"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 “rimuovi” invece di “elimina” e “usa” invece di “utilizza”. In caso di dubbio, scegli la parola più corta e comune.

I formati di data e numero variano significativamente tra i vari 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 formattarli automaticamente in base al locale dell’utente.

JavaScript:

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

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

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

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

Ruby on Rails:

"$#{price}"

"$#{price}"

number_to_currency(price, locale: I18n.locale)

number_to_currency(price, locale: I18n.locale)

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

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 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 di regioni specifiche.

Prendi il francese come esempio:

Quando imposti i tuoi file di lingua, 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.

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 nell’interfaccia utente, a cosa si riferisce o quanto spazio ha la traduzione per adattarsi.

Una stringa come “Annulla” potrebbe riferirsi all’annullamento di un ordine, di un abbonamento o dell’invio di un modulo. Ognuno di questi potrebbe essere tradotto in modo diverso a seconda della lingua.

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

{
  // 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."
}

{
  // 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 screenshot che mostrano dove appaiono queste stringhe. Ciò consente agli strumenti di traduzione di produrre traduzioni significativamente più accurate rispetto al lavoro sul solo testo.

Una volta che le tue stringhe sono nei file di risorse e la tua interfaccia utente è 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']
    }
  });

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

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 manca un file di traduzione 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;

// 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.

Un flusso di lavoro 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 saltato 12 stringhe e ricomincia da capo. Non è scalabile.

Uno strumento di localizzazione software gestisce l’intero flusso di lavoro per te. Uno buono saprà:

• Connettersi al tuo repository, rilevare stringhe nuove e modificate e mantenere le traduzioni aggiornate continuamente
• Dare al tuo team un luogo centrale per gestire tutte le traduzioni
• Includere funzioni 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.

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

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 del software?

Una buona localizzazione del software non deve essere costosa. Il fattore più importante nel tuo budget non è il numero di lingue supportate. È il modo in cui traduci.

La traduzione umana professionale per il software costa tipicamente tra 0,10 $ e 0,30 $ a 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 prodotto cambia.

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

Dopo la prova gratuita, PTC funziona con un modello di pagamento a consumo. Le tue prime 500 parole ogni mese sono gratuite. Più traduci, più bassa è la tua tariffa a parola, e una volta raggiunta una tariffa più bassa, la mantieni 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.

Imposta il tuo processo di localizzazione del software in 3 passaggi

Le best practice per la localizzazione del 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 dei cambiamenti delle stringhe, la gestione dei file di traduzione, la segnalazione di problemi di lunghezza e il mantenimento delle traduzioni sincronizzate, può essere automatizzato con lo strumento giusto.

Ecco come mettere in atto un processo di localizzazione funzionante con PTC.

01

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.

Quindi, aggiungi il contesto sulla tua app: cosa fa e a chi è rivolta. Questo è ciò che rende le traduzioni di PTC accurate invece che generiche. Puoi anche aggiungere un glossario di termini che dovrebbero essere sempre tradotti in un modo specifico, come nomi di prodotti o terminologia tecnica.

PTC le traduce automaticamente, applicando il tuo contesto e il tuo glossario a ogni stringa. L’intera configurazione richiede meno di 5 minuti.

02

Visualizza e perfeziona le traduzioni

Una volta che le traduzioni sono pronte, rivedile dalla tua dashboard. Puoi modificare manualmente le singole stringhe o aggiungere membri del team per gestire le revisioni in lingue specifiche.

Se noti una traduzione che potrebbe essere migliore, segnalala e spiega a PTC qual è il problema. PTC la ritraduce gratuitamente e applica quanto appreso alle future traduzioni nel tuo progetto.

PTC controlla anche la lunghezza della traduzione automaticamente. Le stringhe che potrebbero essere troppo lunghe per la tua interfaccia utente sono evidenziate in giallo. Puoi chiedere a PTC di ritradurle per adattarle, o regolare i limiti di lunghezza per corrispondere a ciò che la tua interfaccia utente consente.

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 tra 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, flussi di lavoro automatizzati e modelli ibridi. Niente ha risolto il problema.

Da quando sono passati a PTC, i rilasci escono in tempo. Le traduzioni sono complete, accurate e coerenti in tutte le 23 lingue, senza blocco delle stringhe, senza oneri 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