Best practice per la localizzazione di software: 10 passaggi con esempi

Questa guida la accompagna attraverso il processo di localizzazione di software dall'inizio alla fine, con best practice e veri esempi di codice.

La sua app è appena stata lanciata in Francia. Le iscrizioni arrivano, e poi i ticket di assistenza iniziano a invadere la sua casella di posta. Gli utenti non riescono a fare clic sul pulsante « Acquista ora » perché è stato tagliato. I menu di navigazione si spezzano su due righe. La sua interfaccia accuratamente progettata sembra completamente rotta.

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

Questa guida copre tutto ciò di cui ha bisogno per fare bene la localizzazione di software. Imparerà:

• Cos'è la localizzazione di software
• La differenza tra localizzazione, traduzione e internazionalizzazione
• Come prepararsi al processo di localizzazione di software
• Le best practice per i contenuti dinamici, l'espansione del testo, la formattazione specifica per le impostazioni locali e i test
• Il costo della localizzazione di software
• Come impostare un flusso di lavoro di localizzazione che non si rompe a ogni release

Cos'è la localizzazione di software?

La localizzazione di software è il processo di adattamento del proprio software a un mercato specifico. Questo va oltre la traduzione del testo. Significa adattare tutto ciò che influisce sul modo in cui gli utenti del mercato di destinazione vivono il software: formati di data e numero, valuta, layout dell'interfaccia, immagini e riferimenti culturali.

L'obiettivo è far sì che il software dia l'impressione di essere stato costruito per quel mercato fin dall'inizio.

Ecco un esempio che mostra come una stessa data possa significare due cose diverse a seconda di dove si trova l'utente:

Questo è un piccolo esempio di ciò che gestisce la localizzazione di software. Lo moltiplichi per date, valute, formati e riferimenti culturali, e inizierà a cogliere la portata del lavoro.

Localizzazione di software vs traduzione vs internazionalizzazione

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

Il processo di localizzazione di software

La localizzazione di software non è un singolo passaggio che si completa prima del lancio. È un processo continuo che si svolge parallelamente allo sviluppo. Ecco una panoramica di come si articola tipicamente:

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

1. A cascata La localizzazione inizia dopo il completamento dello sviluppo. Si termina la costruzione, poi si consegna tutto per la traduzione in un unico lotto. È semplice da gestire, ma ritarda il rilascio nelle altre lingue e rende costosa la correzione dei bug in quella fase.
2. Localizzazione agile La localizzazione si svolge parallelamente allo sviluppo. Invece di un unico grande lotto alla fine, si inviano le stringhe per la traduzione durante l'intero ciclo di sviluppo. La tempistica è migliore, ma il processo è ancora manuale. Qualcuno nel suo team deve esportare le stringhe, gestire i passaggi di consegna e reimportare le traduzioni.
3. Localizzazione continua La localizzazione è completamente automatizzata. Il suo repository si collega direttamente al suo strumento di traduzione, così quando una stringa cambia, viene inviata automaticamente per la traduzione. Quando la traduzione è pronta, viene reintegrata automaticamente.

Best practice per la localizzazione di software

Ogni progetto è diverso, e le sue esigenze di localizzazione dipenderanno dal suo stack, dai suoi mercati di destinazione e dal suo team. Questo elenco copre l'essenziale di ciò che fa funzionare la localizzazione di software.

Memorizzi tutto il testo traducibile in file separati

Quando si codifica il testo direttamente nel codice sorgente, gli strumenti di traduzione non riescono a trovarlo. Questi strumenti funzionano analizzando i file di risorse come JSON, PO o YAML alla ricerca di stringhe da tradurre. Se il suo testo è sepolto nei suoi file JavaScript, PHP o Ruby, l'analisi torna 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 prima rifattorizzare migliaia di stringhe.

Per questo è meglio spostare tutto il testo visibile agli utenti in file di risorse dedicati fin dall'inizio. Questo include tutto ciò che i suoi utenti possono vedere:

• Etichette, pulsanti e voci di menu dell'interfaccia
• Messaggi di errore e testo di convalida
• Modelli di e-mail e notifiche
• Testo di aiuto, suggerimenti e testo segnaposto
• Messaggi di successo e di conferma

Il formato di file da utilizzare dipende dal suo framework:

Ecco un prima e dopo per ogni framework principale.

React :

Prima

<button>Submit</button>

Dopo, con react-intl

<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, con Rails I18n :

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

È anche importante dare alle sue stringhe chiavi chiare e descrittive. Una chiave denominata checkout.submit_button indica a un traduttore esattamente 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 suo stesso team tenere traccia di quali stringhe sono state esternalizzate e individuare ciò che manca.

Usi segnaposto per nomi, numeri e date

Quando il suo testo include dati variabili come il nome di un utente o un numero d'ordine, è allettante 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 appare in una posizione diversa nella frase. I suoi traduttori non possono riordinare i frammenti, quindi la frase finisce per essere grammaticalmente errata.

I segnaposto risolvono questo problema mantenendo la frase intera. I suoi traduttori o il suo strumento di traduzione ricevono la frase completa su cui lavorare, incluso un marcatore che indica dove va la variabile. Possono collocare quel marcatore dove la grammatica della loro lingua lo richiede.

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.

Costruisca la sua interfaccia per gestire testi più lunghi

La maggior parte delle lingue è più lunga dell'inglese. Un pulsante che si adatta perfettamente alla sua interfaccia in inglese verrà spesso tagliato in tedesco, francese o spagnolo. Se ha costruito il layout intorno a larghezze fisse, avrà un'interfaccia rotta in ogni lingua che aggiunge.

Questi sono i tassi di espansione tipici con cui sta lavorando:

Le singole parole possono espandersi ben oltre queste medie. « FAQ » diventa « Preguntas frecuentes » in spagnolo - ovvero un aumento del 567 %.

La soluzione consiste nel costruire layout flessibili anziché fissi. Invece di impostare una larghezza fissa su un pulsante, lo lasci crescere con il suo contenuto:

Prima - una 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;
}

Ci pensi già in fase di progettazione. Se progetta prima per l'inglese e traduce in seguito, passerà più tempo a correggere i problemi di layout in ogni lingua di quanto ne avrebbe speso a integrare la flessibilità fin dall'inizio.

Scriva un testo facile da tradurre

Il modo in cui scrive il suo testo di origine influisce sulla qualità della traduzione. Le formulazioni vaghe, le espressioni idiomatiche e i giochi di parole astuti producono spesso 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 alcun risultato? Il suo traduttore deve indovinare, e un'ipotesi sbagliata significa una traduzione sbagliata.

Scriva frasi complete con un soggetto e un verbo chiari.

Prima - ambiguo

"No items"

Dopo - significato chiaro

"You have no items in your cart."

Espressioni idiomatiche

« This is a piece of cake » ha senso per un madrelingua inglese. Tradotta letteralmente in tedesco, i suoi utenti si chiederanno perché la sua app parla di dessert. 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. Scriva « remove » invece di « eliminate » e « use » invece di « utilize ». In caso di dubbio, scelga la parola più corta e più comune.

Gestisca correttamente date, numeri e valute

I formati di data e numero variano notevolmente tra le impostazioni locali. Codificare questi formati causa lo stesso problema della codifica del testo: funziona in un mercato e si rompe negli altri.

Utilizzi le utilità di localizzazione integrate del suo framework per formattare questi elementi automaticamente in base alle impostazioni locali 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 impostazione locale che supporta.

Pianifichi per le impostazioni locali, non solo per la lingua

La lingua e le impostazioni locali non sono la stessa cosa. Lo spagnolo è una lingua. Lo spagnolo messicano (es-MX), lo spagnolo di Spagna (es-ES) e lo spagnolo argentino (es-AR) sono impostazioni locali. Le differenze tra di loro vanno oltre il vocabolario. I formati di data, la valuta, i riferimenti culturali e il tono possono variare tutti.

Se specifica solo un codice di lingua senza un'impostazione locale, rischia di mostrare il contenuto sbagliato agli utenti di regioni specifiche.

Prenda il francese come esempio:

Quando configura i suoi file di lingua, utilizzi codici di impostazione locale completi anziché soli codici di lingua. Questo le dà la flessibilità di servire contenuti diversi a regioni diverse senza dover ristrutturare la sua configurazione in seguito.

Dia ai traduttori il contesto di cui hanno bisogno

Se decide di lavorare con traduttori umani, tenga presente che lavorano direttamente dai suoi file di risorse. Senza informazioni aggiuntive, tutto ciò che vedono è la stringa stessa. Non hanno modo di sapere dove appare nell'interfaccia, a cosa si riferisce o quanto spazio ha a disposizione 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 tradursi diversamente a seconda della lingua.

Aggiunga commenti ai suoi 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 utilizza uno strumento di traduzione, la maggior parte delle piattaforme consente di allegare screenshot che mostrano dove appaiono queste stringhe. Questo permette agli strumenti di traduzione di produrre traduzioni notevolmente più accurate rispetto a quando lavorano solo con il testo.

Imposti il rilevamento della lingua

Una volta che le sue stringhe sono nei file di risorse e la sua interfaccia è flessibile, deve mostrare automaticamente la lingua giusta a ogni utente. La maggior parte dei framework gestisce questo 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

Imposti sempre una lingua di ripiego. Quando un file di traduzione è mancante o una stringa non è ancora stata tradotta, la sua app mostra il ripiego anziché una chiave rotta come auth.login_error.

Per le app web, può anche consentire agli utenti di sovrascrivere manualmente la lingua rilevata. Memorizzi 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.

Imposti il rilevamento della lingua

Un flusso di lavoro di localizzazione manuale assomiglia a questo: esportare le stringhe in un foglio di calcolo, inviarlo a un traduttore, attendere diversi giorni, riceverlo indietro, copiare le traduzioni nei suoi file, scoprire di aver tralasciato 12 stringhe e ricominciare da capo. Non è scalabile.

Uno strumento di localizzazione di software gestisce l'intero flusso di lavoro per lei. Un buon strumento saprà:

• Collegarsi al suo repository, rilevare le stringhe nuove e modificate e mantenere le traduzioni aggiornate in modo continuo
• Dare al suo team un luogo centrale per gestire tutte le traduzioni
• Includere funzionalità CAT integrate come memoria di traduzione, rilevamento dei limiti di lunghezza e gestione della terminologia

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

Scopri come PTC gestisce la localizzazione del software

Testi ogni versione localizzata prima del lancio

La traduzione non è il passaggio finale. Prima di spedire una versione localizzata, la testi nello stesso modo in cui testerebbe qualsiasi altra release.

Layout: Il testo si adatta senza essere tagliato? La navigazione funziona ancora, o sta osservando degli 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 l'impostazione locale? I numeri e le valute sono formattati correttamente? Il simbolo della valuta è nella posizione giusta?

Lingue da destra a sinistra: Se supporta l'arabo o l'ebraico, testi separatamente il layout RTL completo. Il supporto RTL riguarda più della sola direzione del testo. Influisce sull'intero layout della sua interfaccia.

Integri i test di localizzazione nel suo processo di controllo qualità fin dall'inizio. Trovare un processo di pagamento difettoso in tedesco tramite le recensioni degli utenti è notevolmente più costoso che individuarlo prima del lancio.

Quanto costa la localizzazione di software?

Una buona localizzazione di software non deve essere costosa. Il fattore più importante per il suo budget non è quante lingue supporta. È il modo in cui traduce.

La traduzione umana professionale per il software costa in genere tra 0,10 $ e 0,30 $ per parola. Per un'app di medie dimensioni con 15.000 parole, sono da 1.500 $ a 4.500 $ per lingua, prima ancora di considerare i test, la gestione del progetto o i futuri aggiornamenti a ogni cambiamento del suo prodotto.

La traduzione con IA con uno strumento come PTC costa una frazione di tutto ciò:

Dopo la prova gratuita, PTC funziona con un modello Pay-As-You-Go. Le sue prime 500 parole ogni mese sono gratuite. Più traduce, più basso diventa il suo costo per parola, e una volta raggiunta una tariffa inferiore, la mantiene per tre mesi anche se il suo volume diminuisce.

Per ottenere una cifra esatta per il suo progetto, utilizzi il calcolatore di prezzi di PTC o carichi direttamente il suo file di risorse per vedere il costo prima di impegnarsi.

Calcola il tuo costo di traduzione

Imposti il suo processo di localizzazione di software in 3 passaggi

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

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

Si iscriva a PTC

Crei un progetto in PTC, carichi i suoi file di risorse e selezioni le sue lingue di traduzione. Durante la prova gratuita, può selezionare 2 lingue.

PTC genera automaticamente una descrizione della sua app in base al file caricato. Esamini la descrizione e la mantenga o la modifichi. Può anche caricare traduzioni esistenti e aggiungere un glossario di termini che devono sempre essere tradotti in un modo specifico, come nomi di prodotti o terminologia tecnica.

L'intera configurazione richiede meno di 5 minuti.

Visualizzi e affini le traduzioni

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

PTC Visual QA va oltre il processo standard di revisione a livello di stringa esaminando la sua interfaccia reale in ogni lingua di destinazione.

Ciò che smette di fare:

• Aprire manualmente il suo prodotto in ogni lingua di destinazione per verificare i problemi di visualizzazione
• Coordinare i revisori del controllo qualità che parlano le lingue di destinazione
• Scoprire layout rotti o stringhe mancanti dopo una release

Ciò che ottiene invece:

• PTC rivede visivamente la sua interfaccia 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 rivista prima del rilascio, in minuti anziché ore

Per iniziare, vada alla scheda AI Visual QA dal suo dashboard. A seconda del tipo di software che traduce, potrà caricare screenshot della sua interfaccia oppure utilizzare l'estensione del browser PTC Visual QA per registrare le schermate da rivedere.

PTC analizza i problemi che appaiono solo quando la sua app è in esecuzione. Corregge automaticamente i problemi a livello di traduzione, come formulazioni goffe, tono errato o testo che non si adatta al contesto. I problemi a livello di codice, come chiavi mancanti, stringhe codificate e bug di formattazione, vengono segnalati affinché il suo team li risolva nella sorgente.

Colleghi il suo flusso di lavoro di sviluppo

Quando si trova a suo agio con il funzionamento di PTC, passi a Pay-As-You-Go per accedere alle funzionalità Pro, come il collegamento di PTC al suo repository GitHub, GitLab o Bitbucket. Con questa integrazione, PTC rileva automaticamente le stringhe nuove e modificate e mantiene aggiornate le sue traduzioni senza caricamenti manuali di file.

Se vuole andare oltre, l'API PTC le consente di integrare la traduzione direttamente nella sua pipeline CI/CD, in modo che le versioni localizzate siano sempre pronte per essere spedite insieme alla sua lingua di origine.

Inizia a usare PTC gratuitamente per 30 giorni

Esempio di localizzazione di software: tradurre WPML con PTC

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

Per anni, il team lo ha fatto nel modo tradizionale: assumere traduttori umani professionisti, gestire i file di glossario e coordinare gli aggiornamenti tra 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 alternative: crowdsourcing, flussi di lavoro automatizzati e modelli ibridi. Niente ha risolto il problema.

Da quando sono passati a PTC, le release escono in tempo. Le traduzioni sono complete, accurate e coerenti in tutte le 23 lingue, senza blocco delle stringhe, senza sovraccarico di coordinamento e senza ritardi.

Prima di PTC

Dopo PTC

Inizi a localizzare il suo software oggi stesso

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

Inizia la tua prova gratuita