Come localizzare un'app mobile

Se stai cercando come localizzare un’app mobile, probabilmente non hai bisogno di “consigli di traduzione”. Hai bisogno di un flusso di lavoro sicuro per il rilascio che copra le stringhe dell’app, il layout, le regole dei plurali, il supporto da destra a sinistra, gli screenshot e i metadati dello store senza danneggiare il prodotto.

Questa è la distinzione fondamentale: la localizzazione di un’app mobile non è semplicemente tradurre testo. Significa adattare l’app, la pagina del prodotto e il processo di QA per ogni mercato di destinazione. Apple afferma che l’App Store è disponibile in 175 regioni e 40 lingue, mentre Android 13 ha introdotto le preferenze linguistiche per app a livello di sistema. In altre parole, entrambe le piattaforme principali ora considerano la scelta della lingua un’esperienza di prodotto fondamentale, non un ripensamento.

Questa guida illustra i passaggi pratici per i team iOS e Android.

In sintesi:

• Separare la localizzazione in-app dalla localizzazione su App Store e Google Play.
• Esternalizzare le stringhe prima di tradurre qualsiasi cosa.
• Gestire plurali, variabili, date, valute e RTL fin dall’inizio.
• Testare con pseudolingue prima di rilasciare le traduzioni reali.
• Localizzare screenshot e risorse dello store, non solo le descrizioni.

Cosa include effettivamente la localizzazione di un’app mobile

Il lavoro di localizzazione si divide generalmente in due filoni.

1. Localizzazione in-app

Riguarda il prodotto stesso:

• Stringhe dell’interfaccia utente
• Messaggi di errore e testi di onboarding
• Date, orari, numeri, valute e unità di misura
• Stringhe sensibili a plurali e genere
• Espansione del layout e comportamento da destra a sinistra
• Immagini o icone che contengono testo o significato direzionale

Apple raccomanda esplicitamente di utilizzare Xcode, le API Foundation, Auto Layout, il supporto Unicode, i cataloghi di risorse localizzate e i simboli sensibili alla direzione per preparare le app ai mercati globali. Analogamente, Android raccomanda risorse sensibili alla localizzazione, supporto linguistico per app e layout compatibili con RTL invece di testo e posizionamento hardcoded.

2. Localizzazione della scheda dello store

Riguarda il modo in cui gli utenti scoprono la tua app:

• Nome dell’app
• Sottotitolo o descrizione breve
• Descrizione completa
• Parole chiave
• Screenshot
• Anteprime dell’app o video promozionali

Trattala come un deliverable separato. Un’app ben localizzata può comunque sottoperformare se la pagina del prodotto è generica, non tradotta o visivamente inadatta al mercato di destinazione.

Inizia con l’internazionalizzazione, non con la traduzione

La traduzione è l’ultimo passaggio di un processo che inizia con la struttura.

Esternalizza le stringhe e mantieni un locale di fallback completo

Su Android, Google avverte che il file predefinito res/values/strings.xml deve definire ogni stringa di cui l’app ha bisogno. Se il file predefinito è incompleto e il dispositivo viene eseguito in un locale non supportato, l’app potrebbe non caricarsi e mostrare un errore con il pulsante Chiusura forzata. Ecco perché la localizzazione inizia con l’igiene delle risorse, non con la selezione della lingua.

Per iOS, Apple raccomanda di separare il testo e le immagini visibili all’utente dal codice eseguibile, in modo che possano essere localizzati come file di risorse. Nei flussi di lavoro Apple moderni, i cataloghi di stringhe sono l’approccio consigliato in Xcode 15 e versioni successive per le stringhe che contengono plurali.

Regola pratica:

• non inserire mai testo dell’interfaccia direttamente nelle viste o nei controller
• mantieni una singola lingua sorgente canonica
• assicurati che ogni stringa visibile all’utente abbia una chiave stabile, un contesto e un fallback
• includi commenti per i traduttori per le stringhe ambigue

Un piccolo esempio rende tutto più chiaro.

Su Android di solito si parte con un file strings.xml predefinito:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Poi la tua interfaccia legge la risorsa invece di avere l’inglese hardcoded:

Text(text = stringResource(R.string.checkout_cta))

Sulle piattaforme Apple, Xcode 15+ spesso gestisce la stessa idea in un catalogo di stringhe. Un estratto semplificato di Localizable.xcstrings può apparire così:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Non è necessario memorizzare il formato del file. La lezione operativa è più semplice: ogni stringa visibile all’utente ha bisogno di un’unica fonte di verità, di un contesto sufficiente per i traduttori e di un fallback sicuro quando un locale è incompleto.

Se la tua app include anche file linguistici strutturati, la nostra guida ai Best JSON Translators in 2026 può aiutarti a ragionare su automazione e preservazione del formato.

Se desideri uno strumento diretto per i file di risorse dell’app, vale la pena dare un’occhiata a OpenL JSON Translator. È progettato per tradurre file .json senza alterare chiavi o struttura, che è esattamente ciò che serve quando le stringhe dell’app sono memorizzate in file di localizzazione leggibili dalle macchine. Il flusso di lavoro è semplice: carica il JSON esportato dalla tua app, CMS o pipeline di localizzazione, scegli la lingua di destinazione e scarica un file JSON tradotto con la stessa struttura. Secondo la pagina del prodotto, supporta oltre 100 lingue e file fino a 50 MB, rendendolo uno strumento pratico per una prima bozza per i team di localizzazione di app che gestiscono contenuti strutturati.

Supporta la selezione della lingua a livello di app

Gli utenti si aspettano sempre più di poter scegliere la lingua dell’app separatamente dalla lingua del dispositivo.

Sulle piattaforme Apple, gli utenti possono selezionare la lingua preferita per un’app indipendentemente dalla lingua del dispositivo. Su Android, Android 13 ha aggiunto un’impostazione centralizzata per la lingua dell’app, e Google raccomanda di abilitare il supporto automatico per la lingua per app o di collegare il selettore alle API ufficiali.

Questo è importante per i prodotti reali. Gli utenti bilingui e multilingui potrebbero mantenere il telefono in inglese ma preferire un’app di shopping, banking o consegne in un’altra lingua. Se la tua app impone un unico modello linguistico, stai creando attrito prima ancora che la qualità della traduzione diventi un problema.

Usa lo stack di localizzazione della piattaforma

Resisti alla tentazione di inventare un sistema di localizzazione parallelo, a meno che non ne abbia davvero bisogno.

Per la maggior parte dei team, lo stack predefinito della piattaforma è sufficiente:

• iOS: cataloghi di stringhe, Localizable.strings, .stringsdict, formattatori Foundation, Auto Layout
• Android: res/values/, cartelle di risorse specifiche per locale, LocaleConfig, setApplicationLocales(), supportsRtl

Un’infrastruttura di localizzazione personalizzata ha senso su scala molto ampia, ma aggiunge overhead operativo. Inizia con il sistema nativo, poi estendi solo dove senti un vero problema.

Localizza le parti che la maggior parte dei team trascura

I team spesso traducono le frasi visibili e tralasciano i meccanismi del prodotto che le circondano.

Plurali, variabili e grammatica

Le regole dei plurali non sono universali. Le regole dei plurali Unicode CLDR definiscono categorie come zero, one, two, few, many e other, e lingue diverse utilizzano sottoinsiemi diversi. Apple nota che nei vecchi flussi di lavoro .stringsdict, other è l’unica categoria obbligatoria, ma saltare le categorie specifiche della lingua può comunque produrre output grammaticalmente errato. Sia Android che iOS si affidano alla gestione dei plurali sensibile al locale per un motivo.

È qui che la traduzione automatica ingenua fallisce:

• 1 file vs 2 files è facile in inglese
• Le lingue slave spesso richiedono più di due forme plurali
• Alcune lingue modificano contemporaneamente sostantivi, verbi o parole circostanti

Non costruire mai interfacce con plurali concatenando frammenti come "You have " + count + " messages". Usa invece le risorse plurali della piattaforma.

Ecco la struttura minima su ciascuna piattaforma.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Esempio legacy iOS .stringsdict:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

In Xcode 15 e versioni successive, Apple raccomanda di gestire i plurali nei cataloghi di stringhe, ma il principio rimane lo stesso: dai alla piattaforma un modello di messaggio e lascia che scelga la forma linguistica corretta.

Per approfondire le salvaguardie del flusso di lavoro relative a segnaposto e stringhe strutturate, consulta How to Translate Technical Docs Without Breaking Code.

Date, numeri, valute e unità di misura

Apple raccomanda esplicitamente di utilizzare le API Foundation per formattare date, lunghezze, pesi, prezzi e simboli delle valute tra i diversi locali. Lo stesso principio si applica su Android: formattare i dati con API sensibili al locale invece di inserire a mano punteggiatura, separatori decimali o ordine delle unità.

Errori tipici includono:

• 03/04/2026 che significa cose diverse in regioni diverse
• Segni del dollaro hardcoded per mercati non in USD
• 1,234.56 visualizzato in modo errato nei locali che usano la virgola come separatore decimale
• Unità di misura mostrate nel sistema sbagliato

Se la tua app contiene pianificazione, fatturazione, finestre di consegna o analisi, questo fa parte della localizzazione, non è un dettaglio estetico.

Espansione del layout e supporto da destra a sinistra

L’inglese è generalmente compatto. Il tedesco diventa più lungo. L’arabo e l’ebraico invertono la direzione di lettura. Un layout che funziona bene in inglese può rompersi in altri locali.

Apple raccomanda di testare con pseudolingue, inclusa una pseudolingua da destra a sinistra e una pseudolingua a lunghezza doppia, prima ancora di importare le traduzioni reali. Android raccomanda di usare start e end al posto di left e right, abilitare android:supportsRtl="true" e testare i layout RTL sul dispositivo con Force RTL.

La tua checklist qui è semplice:

• Permettere a pulsanti ed etichette di espandersi
• Evitare contenitori di testo a larghezza fissa per l’interfaccia importante
• Specchiare l’interfaccia direzionale dove appropriato
• Verificare icone, chevron, flussi di avanzamento e caroselli in RTL
• Testare testo a direzione mista come interfaccia in arabo con nomi di prodotti latini o codici promozionali

Immagini, icone, screenshot e video

La guida alla localizzazione di Apple fa un punto importante che molti team trascurano: anche le immagini possono essere localizzate. Questo include set di immagini, set di simboli e la direzionalità per i simboli personalizzati. Se il tuo screenshot contiene interfaccia in inglese, testo in inglese nei banner o frecce da sinistra a destra, allora lo screenshot stesso non è localizzato.

Questo è particolarmente importante per le schermate di onboarding, le schede tutorial e le risorse dell’App Store. Gli utenti non separano mentalmente “materiali di marketing” da “lingua del prodotto”. Giudicano l’intera esperienza nel complesso.

Localizza le pagine dell’App Store e di Google Play separatamente

È qui che molti team perdono installazioni anche dopo aver fatto bene il lavoro in-app.

Requisiti dell’App Store da considerare

Apple raccomanda di localizzare i metadati in App Store Connect, inclusa la descrizione dell’app, le parole chiave, le anteprime dell’app e gli screenshot. Apple afferma inoltre che puoi mostrare fino a 10 screenshot nella pagina del prodotto e fino a 3 anteprime dell’app per dimensione del dispositivo e lingua supportata. Le anteprime dell’app possono durare fino a 30 secondi, e gli screenshot contano ancora di più quando non è presente un’anteprima perché i primi uno-tre screenshot possono apparire nei risultati di ricerca.

Questo ha due implicazioni:

1. I tuoi primi screenshot sono risorse per la scopribilità, non solo documentazione.
2. Dovresti localizzare screenshot e anteprime per i mercati prioritari invece di riutilizzare le risorse in inglese ovunque.

Requisiti di Google Play da considerare

Google Play tratta la localizzazione della scheda come un flusso di lavoro a sé. Play Console ti permette di aggiungere testo localizzato, screenshot nella lingua di destinazione e risorse grafiche localizzate. Se aggiungi traduzioni testuali senza risorse grafiche localizzate, Google afferma che verranno comunque mostrate le risorse visive nella lingua predefinita.

Google nota inoltre che se non aggiungi le tue traduzioni della scheda dello store, gli utenti potrebbero vedere una traduzione automatica con un avviso che è stata generata automaticamente. Utile come fallback, ma non è una strategia di ingresso sul mercato efficace.

Una funzionalità attuale particolarmente rilevante: Play Console afferma di poter tradurre continuamente le stringhe dell’app usando modelli Gemini senza costi. Più specificamente, Google afferma che questo si applica alle stringhe dell’app da strings.xml nei bundle caricati nelle release in bozza, e che puoi visualizzare in anteprima le traduzioni generate in un emulatore integrato prima della pubblicazione. È un ottimo modo per accelerare la copertura iniziale, ma dovrebbe comunque essere seguito da una revisione umana per i flussi critici.

Costruisci un flusso di lavoro per rilascio e QA

Un buon processo di localizzazione riguarda meno il tradurre più velocemente e più il rilasciare meno sorprese.

Passaggio 1. Scegli i locali di destinazione con attenzione

Non iniziare con “traduci tutto in 20 lingue”.

Inizia con:

• Il tuo attuale mix di download
• I paesi che supporti attivamente
• La copertura di fatturazione, legale e supporto clienti
• Se puoi localizzare insieme sia l’app che la scheda dello store

Rilasciare un mercato end-to-end di solito batte rilasciare cinque mercati a metà.

Passaggio 2. Crea risorse pronte per la localizzazione

Prima che la traduzione inizi, congela e prepara:

• Stringhe sorgente con contesto
• Lista di screenshot per locale
• Glossario e regole per i nomi dei prodotti
• Regole per i segnaposto
• Linee guida sui limiti di caratteri per i testi dello store
• Responsabili della revisione specifici per locale

Se l’app usa repository separati o formati di file multipli, standardizza la nomenclatura e l’estrazione in anticipo.

Passaggio 3. Testa prima con la pseudolocalizzazione

Sulle piattaforme Apple, usa le pseudolingue a lunghezza doppia e da destra a sinistra. Su Android, testa locali non supportati, Force RTL e impostazioni della lingua dell’app. Questo rileva:

• Pulsanti troncati
• Intestazioni tagliate
• Testo nascosto
• Allineamento errato
• Stringhe non localizzate
• Assunzioni hardcoded left/right

Questo è uno dei test QA più economici che puoi eseguire.

Passaggio 4. Esegui QA linguistico su dispositivi reali

Dopo che le traduzioni sono state integrate:

• Testa i flussi critici in ogni lingua di destinazione
• Confronta il comportamento della lingua di sistema e della lingua dell’app
• Verifica il comportamento dei plurali e dei segnaposto
• Controlla pagamenti, date e indirizzi
• Rivedi screenshot e schede dello store nel mercato di destinazione

Se un bug influisce su onboarding, checkout, verifica dell’identità o notifiche, trattalo come un bloccante per il rilascio.

Una checklist per il primo sprint di localizzazione

Se questo è il tuo primo rilascio serio, mantieni lo sprint abbastanza piccolo da completarlo in modo pulito:

• Scegli 1 locale di destinazione, non 10.
• Congela le stringhe sorgente per un branch di rilascio.
• Esporta tutte le stringhe di onboarding, checkout, account e notifiche con commenti di contesto.
• Cattura gli screenshot che vuoi localizzare per App Store e Google Play.
• Esegui un passaggio di pseudolocalizzazione prima di inviare il testo reale ai traduttori.
• Traduci le stringhe dell’app e i testi della scheda dello store nello stesso sprint.
• Reimporta le traduzioni e testa il cambio lingua dell’app sia su iOS che su Android.
• QA dei 5 principali percorsi utente su dispositivi reali.
• Aggiorna screenshot, anteprime dell’app e metadati dello store per lo stesso locale.
• Rilascia prima su TestFlight o su un track interno, poi monitora i ticket di supporto e i report di crash.

Questa checklist è volutamente ristretta. Un locale con un’esperienza app pulita e risorse dello store sincronizzate ti insegna molto di più di un lancio frettoloso su molti mercati.

Esempi dal mondo reale

Le idee fondamentali sopra esposte non sono teoriche.

DoorDash ha affrontato la traduzione come un problema di piattaforma

Nel 2022, DoorDash ha dichiarato di aver già tradotto più di un milione di stringhe in quattro lingue e di aver ridotto l’onboarding per nuove lingue da ore di lavoro per gli sviluppatori a un singolo comando in un minuto. La lezione interessante non è solo la scala. È la struttura: DoorDash ha separato le stringhe statiche da quelle dinamiche, ha aggiunto il supporto per glossario e guida di stile, e ha costruito protezioni per evitare che stringhe non tradotte passassero inosservate.

In un post sul blog di DoorDash del 2 febbraio 2026, l’azienda ha dichiarato che la sua piattaforma di onboarding ricostruita ora gestisce le registrazioni in tutti i mercati DoorDash e supporta lanci internazionali rapidi con localizzazione integrata. Questo è esattamente l’aspetto di una localizzazione matura: flussi di lavoro riutilizzabili, flessibilità regionale e meno soluzioni improvvisate.

Meta ha trattato la localizzazione sia come un problema linguistico che come un problema di dimensioni dell’app

Meta afferma che circa il 57% degli utenti di Facebook per Android e il 49% degli utenti di Facebook per iOS utilizzano l’app in una lingua diversa dall’inglese. Nello stesso articolo, Meta afferma che la rimozione dei file di traduzione incorporati ha risparmiato fino a 16,6 MB nell’app iOS e ha permesso ad Android di aggiungere quasi una dozzina di lingue in più senza aumentare le dimensioni dell’app.

La lezione è utile anche per team più piccoli: la localizzazione ha conseguenze ingegneristiche. Influisce sulle dimensioni del binario, sul caricamento a runtime, sulla distribuzione delle traduzioni e sulle meccaniche di rilascio, non solo sulla scrittura dei testi.

Checklist finale prima del rilascio

Usala come ultima verifica:

• Tutte le stringhe visibili all’utente sono esternalizzate.
• Le risorse di fallback predefinite sono complete.
• Plurali e segnaposto utilizzano il supporto nativo della piattaforma per la localizzazione.
• Date, orari, numeri, valute e unità di misura sono sensibili al locale.
• I layout RTL e il testo a direzione mista sono stati testati.
• Il testo della scheda dello store è localizzato per i mercati di destinazione.
• Screenshot e anteprime sono localizzati per le lingue prioritarie.
• La selezione della lingua in-app funziona come previsto su iOS e Android.
• Il QA linguistico ha coperto i percorsi utente più importanti.

Considerazioni finali

Il modo più semplice di pensare alla localizzazione di un’app mobile è questo: traduci il prodotto, localizza l’esperienza e testa il rilascio.

Se lo fai per la prima volta, non puntare a una copertura globale perfetta dal primo giorno. Scegli uno o due locali strategici, localizza l’app e la pagina dello store insieme, esegui un serio passaggio di QA e impara dall’uso reale. Se stai già gestendo file di risorse e contenuti orientati agli sviluppatori, abbina questo flusso di lavoro con How to Translate Technical Docs Without Breaking Code e Best JSON Translators in 2026.

Se puoi compiere una sola azione questa settimana, fai questo: scegli 1 locale, esegui 1 passaggio di pseudolocalizzazione e localizza 1 scheda corrispondente su App Store o Google Play. Questo test in tre parti ti dirà molto di più sulla tua preparazione rispetto a tradurre venti locali in parallelo.

Se hai bisogno di una prima bozza rapida per i testi dell’app, gli screenshot o i file linguistici strutturati, usa l’automazione per accelerare la bozza, poi mantieni un passaggio di QA umano prima del rilascio. È la parte che protegge la fiducia degli utenti e previene un lancio “tradotto ma non veramente localizzato”.

Riferimenti

• Apple Developer. Localization. https://developer.apple.com/localization/
• Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
• Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
• Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
• Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
• Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
• Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
• Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
• Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
• Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
• Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
• Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
• DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
• DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
• Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/