Migliori pratiche per la localizzazione del software: 10 passaggi con esempi

Questa guida ti accompagna lungo il processo di localizzazione del software dall'inizio alla fine, con le migliori pratiche ed esempi di codice reali.

La tua app è appena stata lanciata in Francia. Le registrazioni arrivano numerose, ma poi i ticket di assistenza iniziano a inondare la tua casella di posta. Gli utenti non riescono a fare clic sul pulsante «Acquista ora» perché è tagliato. I menu di navigazione si spezzano su due righe. La tua interfaccia utente, progettata con cura, sembra completamente rotta.

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

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

• Cos'è la localizzazione del software
• La differenza tra localizzazione, traduzione e internazionalizzazione
• Come prepararsi per il processo di localizzazione del software
• Migliori pratiche per il contenuto dinamico, l'espansione del testo, la formattazione specifica per il locale e i test
• Il costo della localizzazione del software
• Come configurare un flusso di lavoro di localizzazione che non si rompa a ogni release

Cos'è la localizzazione del software?

La localizzazione del software è il processo di adattamento del tuo software per un mercato specifico. Questo va oltre la 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 date e numeri, valuta, layout dell'interfaccia utente, immagini e riferimenti culturali.

L'obiettivo è far sembrare che il tuo software sia stato creato 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 del software. Moltiplicalo per date, valute, formati e riferimenti culturali e inizierai a capire 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 si affianca allo sviluppo. Ecco una panoramica di come si suddivide in genere:

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

1. A cascata (Waterfall) La localizzazione inizia dopo il completamento dello sviluppo. Finisci di programmare, poi consegni tutto per la traduzione in un unico batch. È semplice da gestire, ma ritarda la tua release in altre lingue e rende costosa la risoluzione dei bug in quella fase.
2. Localizzazione agile La localizzazione procede parallelamente allo sviluppo. Invece di un unico grande batch alla fine, invii le stringhe per la traduzione durante l'intero ciclo di sviluppo. Le tempistiche sono migliori, ma il processo è ancora manuale. Qualcuno nel tuo team deve esportare le stringhe, gestire i passaggi di consegne e reimportare le traduzioni.
3. Localizzazione continua La localizzazione è completamente automatizzata. Il tuo repository si collega direttamente al tuo strumento di traduzione, quindi quando una stringa cambia, viene inviata automaticamente per la traduzione. Quando la traduzione è pronta, viene unita di nuovo automaticamente.

Migliori pratiche per la localizzazione del 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 gli elementi fondamentali che fanno funzionare la localizzazione del software.

Archivia tutto il testo traducibile in file separati

Quando inserisci testo hardcoded direttamente nel tuo codice sorgente, gli strumenti di traduzione non riescono a trovarlo. Questi strumenti funzionano scansionando i file di risorse come JSON, PO o YAML alla ricerca di stringhe da tradurre. Se il tuo testo è sepolto all'interno dei tuoi file JavaScript, PHP o Ruby, la scansione non restituirà alcun risultato.

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 prima rifattorizzare migliaia di stringhe.

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

• Etichette dell'interfaccia utente, pulsanti e voci di menu
• Messaggi di errore e testi di convalida
• Modelli di email e notifiche
• Testi di aiuto, i tooltip e testo 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, i18n di WordPress

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

Ruby on Rails:

Prima

flash[:notice] = "Profile updated successfully"

Dopo, usando I18n di Rails:

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

È anche importante dare alle tue stringhe chiavi chiare e descrittive. Una chiave chiamata checkout.submit_button dice esattamente a un traduttore dove appare questa stringa e cosa fa. D'altra parte, string_147 non gli dice nulla, il che porta a errori di traduzione. Le chiavi descrittive rendono anche più facile per il tuo team tenere traccia di 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 insieme nel codice. Questo si rompe 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 occupa una posizione diversa nella frase. I tuoi traduttori non possono riordinare i frammenti, quindi la frase finisce per essere grammaticalmente scorretta.

I segnaposto risolvono il problema mantenendo la frase intera. I tuoi traduttori o il tuo strumento di traduzione ottengono l'intera frase 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 in base al formato, ma il principio è lo stesso.

Crea la tua interfaccia utente per gestire testi più lunghi

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 attorno a larghezze fisse, avrai un'interfaccia utente rotta in ogni lingua che aggiungi.

Questi sono i tassi di espansione tipici con cui hai 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 è creare layout flessibili piuttosto che fissi. Invece di impostare una larghezza fissa su un pulsante, lascialo crescere con il suo contenuto:

Prima: la larghezza fissa si rompe con le lingue più lunghe

button { width: 120px; }

Dopo: cresce con il testo tradotto

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

Pensaci in fase di progettazione. Se progetti prima per l'inglese e traduci in un secondo momento, trascorrerai più tempo a eseguire il debug dei problemi di layout in ogni lingua di quanto ne avresti impiegato per integrare la flessibilità fin dall'inizio.

Scrivi testi facili da tradurre

Il modo in cui scrivi il tuo testo di origine influisce sulla qualità della traduzione. Frasi vaghe, modi di dire e abili giochi di parole 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 prodotto risultati? Il tuo traduttore deve tirare a indovinare e un'ipotesi sbagliata significa una traduzione sbagliata.

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” (è un gioco da ragazzi) ha senso per un madrelingua inglese. Tradotto letteralmente in tedesco, i tuoi utenti si chiederanno perché la tua app stia parlando di dessert. La maggior parte delle espressioni funziona solo nella lingua di origine, quindi è meglio evitarle del tutto.

Vocabolario complesso

Le parole semplici si traducono in modo più affidabile. Scrivi “remove” (rimuovere) invece di “eliminate” (eliminare) e “use” (usare) invece di “utilize” (utilizzare). Nel dubbio, scegli la parola più corta e comune.

Gestisci correttamente date, numeri e valute

I formati di date e numeri variano in modo significativo da un locale all'altro. L'inserimento hardcoded di questi formati causa lo stesso problema dell'inserimento hardcoded del testo: funziona in un mercato e si rompe negli altri.

Usa le utilità di localizzazione integrate nel tuo framework per formattarli 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 che supporti.

Pianifica per locale, non solo per 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 locale. Le differenze tra loro vanno oltre il vocabolario. I formati delle date, la valuta, i riferimenti culturali e il tono possono variare.

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

Prendiamo il francese come esempio:

Quando configuri i tuoi file di risorse, usa i codici locale completi anziché solo i codici lingua. Questo ti dà la flessibilità di fornire contenuti diversi a regioni diverse senza dover ristrutturare la tua configurazione in seguito.

Fornisci 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 nell'interfaccia utente, a cosa si riferisce o in quanto spazio deve rientrare la traduzione.

Una stringa come “Cancel” potrebbe riferirsi all'annullamento di un ordine, di un abbonamento o dell'invio di un modulo. Ognuno di questi casi 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:

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 consente di allegare schermate che mostrano dove appaiono queste stringhe. Questo permette agli strumenti di traduzione di produrre traduzioni significativamente più accurate rispetto a quando lavorano solo sul testo.

Configura il rilevamento della lingua

Una volta che le tue stringhe sono nei file di risorse e la tua interfaccia utente è flessibile, devi mostrare automaticamente a ogni utente la lingua giusta. La maggior parte dei framework gestisce questa operazione 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 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 sovrascrivere 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 in genere 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 flusso di lavoro di localizzazione manuale si presenta più o meno così: esporti le stringhe in un foglio di calcolo, lo invii a un traduttore, aspetti diversi giorni, lo ricevi indietro, copi le traduzioni nei tuoi file, scopri che ti sei perso 12 stringhe e ricominci da capo. Non è scalabile.

Uno strumento per la localizzazione del software gestisce l'intero flusso di lavoro per te. Un buon strumento:

• Si collega al tuo repository, rileva le stringhe nuove e modificate e mantiene le traduzioni continuamente aggiornate
• Offre al tuo team un luogo centralizzato per gestire tutte le traduzioni
• Include funzionalità CAT integrate come la memoria di traduzione, il rilevamento del limite di lunghezza e la gestione terminologica

PTC fa tutto questo. Inoltre, la prova copre le tue prime 20.000 parole in 2 lingue e per iniziare bastano meno di 5 minuti.

Scopri come PTC gestisce la localizzazione del software

Testa ogni versione localizzata prima del lancio

La traduzione non è il passaggio finale. Prima di rilasciare una versione localizzata, testala nello stesso modo in cui testeresti qualsiasi altra release.

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

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

Formattazione: Le date sono nel formato giusto per il locale? Numeri e valute sono formattati correttamente? Il simbolo della valuta è nella posizione giusta?

Lingue right-to-left: Se supporti l'arabo o l'ebraico, testa separatamente l'intero layout RTL. Il supporto RTL influisce su molto più che la sola direzione del testo. Influisce sull'intero layout della tua interfaccia utente.

Integra i test di localizzazione nel tuo processo di QA fin dall'inizio. Scoprire un flusso di checkout rotto in tedesco attraverso 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 per forza essere costosa. Il fattore principale nel tuo budget non è quante lingue supporti, ma come traduci.

La traduzione umana professionale per il software in genere costa tra 0,10 $ e 0,30 $ per parola. Per un'app di medie dimensioni con 15.000 parole, si tratta di 1.500 $ - 4.500 $ per lingua, prima di mettere in conto i test, la gestione del progetto o i futuri aggiornamenti ogni volta che il tuo prodotto cambia.

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

Dopo la prova, 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 dei costi di PTC o carica direttamente il tuo file di risorse per vedere il costo prima di impegnarti.

Calcola i costi di traduzione

Configura il tuo processo di localizzazione del software in 3 passaggi

Le migliori pratiche per la localizzazione del software viste sopra coprono molto terreno. Alcune di esse, come scrivere testi traducibili o pianificare in base al locale, richiedono decisioni ponderate da parte del tuo team. Ma gran parte del lavoro tecnico, come rilevare le modifiche alle stringhe, gestire i file di traduzione, segnalare i problemi di lunghezza e mantenere sincronizzate le traduzioni, può essere automatizzato 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, puoi selezionare 2 lingue.

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

L'intera configurazione richiede meno di 5 minuti.

Visualizza e perfeziona le traduzioni

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

L'AI Visual QA spinge oltre il processo standard di revisione a livello di stringa esaminando la tua interfaccia utente reale in ogni lingua di destinazione.

Cosa smetti di fare:

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

Cosa ottieni invece:

• PTC esegue una revisione visiva della tua interfaccia utente tradotta e trova problemi che l'ispezione delle stringhe non può cogliere
• I problemi riscontrati nelle traduzioni generate da PTC vengono risolti automaticamente
• Ogni lingua viene revisionata prima del rilascio, in pochi minuti anziché in 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 le schermate della tua interfaccia utente o usare l'estensione del browser Visual QA di PTC per registrare le schermate per la revisione.

PTC cercherà i problemi che appaiono solo quando la tua app è in esecuzione. Risolve automaticamente i problemi a livello di traduzione, come frasi goffe, tono sbagliato 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 li risolva nel sorgente.

Collega il tuo flusso di lavoro di sviluppo

Quando hai preso confidenza con il funzionamento di PTC, passa a Pay-As-You-Go per accedere alle funzionalità Pro, come il collegamento 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 dei file.

Se vuoi spingerti oltre, l'API di PTC ti consente di integrare la traduzione direttamente nella tua pipeline CI/CD, in modo che le versioni localizzate siano sempre pronte per essere rilasciate insieme alla lingua di origine.

Inizia a usare PTC per 30 giorni

Esempio di localizzazione del software: tradurre WPML con PTC

WPML è uno dei plugin multilingue più usati per WordPress. Mantenerlo tradotto in 23 lingue non è un optional. È parte di ogni release.

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

Hanno provato delle alternative: crowdsourcing, flussi di lavoro automatizzati e modelli ibridi. Nulla ha risolto il problema.

Da quando sono passati a PTC, le release escono in tempo. Le traduzioni sono complete, accurate e coerenti in tutte e 23 le lingue, senza string freeze, senza oneri di coordinamento e senza ritardi.

Prima di PTC

Dopo PTC

Inizia oggi stesso a localizzare il tuo software

La prova di PTC copre le tue prime 20.000 parole in 2 lingue. Per iniziare bastano meno di 5 minuti.

Inizia la tua prova