In quali lingue dovresti localizzare la scheda del tuo app store?
La maggior parte dei consigli su questo tema risponde a una domanda diversa. Chiedi "in quali lingue dovrei localizzare" e la risposta è un muro di statistiche sull'economia globale delle app. Curiosità utile, nessuna decisione. Questo articolo è la decisione.
Ci sono circa 50 lingue per i metadati sull'App Store oggi (Apple è passata da 39 a 50 a marzo 2026, aggiungendo undici lingue perlopiù indiane) e ancora più locale per la scheda su Google Play. Non le farai tutte, e non dovresti. L'obiettivo è una lista breve e ordinata su cui agire questa settimana.
Prima, separa la scheda dall'app
Sono due progetti diversi con costi molto diversi, e confonderli è l'errore più comune.
- La scheda dello store — titolo, sottotitolo, descrizione, parole chiave e screenshot. Tradurre questi elementi cambia ciò che un utente vede prima di installare. Non tocca il codice dell'app e va live subito da App Store Connect e Play Console.
- L'interfaccia dell'app — ogni stringa dentro l'app in esecuzione. Tradurre questa parte è vero lavoro di ingegneria: estrarre le stringhe, collegare un sistema di localizzazione, ritestare ogni schermata, mantenerlo a ogni rilascio.
L'ordine economico e sensato è localizzare prima la scheda e rimandare la traduzione dell'app finché i dati non la giustificano. Nel mondo ASO si chiama localizzazione minima praticabile: metti una vetrina tradotta davanti a un mercato, osserva se le installazioni e (fondamentale) la retention reggono, e solo dopo paghi per tradurre l'app stessa. Una scheda localizzata con un'app in inglese è un test perfettamente valido. Un'app completamente tradotta per un mercato che non converte mai è denaro che non recuperi.
Quindi il modello qui sotto riguarda la scheda. Tratta la traduzione dell'interfaccia app come una decisione separata, successiva, da prendere per ogni mercato, in base alla retention.
Le due forze che tirano in direzioni opposte
I mercati si distribuiscono lungo un asse di spesa e un asse di volume, e i due raramente coincidono. Qui conta più la direzione che la precisione — trattali come indicazioni, non come un listino, perché i numeri esatti cambiano per categoria e per anno.
- Ricavo per utente alto. Alcuni mercati maturi spiccano nella spesa ben oltre la loro popolazione. Il Giappone è il caso più evidente — i suoi titoli di punta hanno storicamente mostrato quasi il doppio del ricavo per utente rispetto agli USA — con Germania e Corea del Sud nella stessa fascia ad alta spesa. Meno download, ma ognuno vale di più.
- Volume di download alto. L'India guida le installazioni globali con ampio margine, con Brasile e Indonesia poco dietro. Portata enorme, ma il ricavo per utente è molto più basso, e la monetizzazione tende ad appoggiarsi su pubblicità e prezzi bassi piuttosto che su installazioni a pagamento o abbonamenti.
Nessuno dei due assi vince del tutto. Un'app in abbonamento premium dovrebbe pesare di più la prima lista; un'app finanziata da pubblicità che vive di scala dovrebbe pesare di più la seconda. La maggior parte delle app vuole un paio da ciascuna, scelte in base al proprio modello di prezzo.
Il modello decisionale
Tre livelli. Seguili in ordine. Fermati dove finisce la tua voglia di manutenzione — una scheda localizzata fino al Livello 1 copre già la maggior parte della spesa mondiale in app.
Livello 1 — inizia da qui. Le lingue che quasi ogni app dovrebbe usare per la scheda, perché combinano pubblici ampi con propensione alla spesa comprovata:
- Spagnolo e Portoghese (Brasile) — portata combinata enorme tra le Americhe e la Spagna.
- Tedesco, Francese, Giapponese — mercati maturi e ad alta spesa dove una scheda in lingua nativa alza in modo misurabile la conversione.
- Cinese semplificato — il singolo store più grande in assoluto, se la tua app è praticabile lì.
Livello 2 — aggiungi dopo. Mercati solidi da raggiungere una volta che il Livello 1 è live e ne hai visto l'effetto sui numeri:
- Coreano e Italiano — più piccoli ma ad alta intenzione, buona conversione.
- Russo e Turco — pubblici ampi, monetizzazione dipendente dalla categoria.
- Portoghese (Portogallo) e Olandese se il tuo prodotto è più orientato all'Europa.
Livello 3 — opzionale. Puntate sul volume e portata di lunga coda. Ne vale la pena quando il costo marginale di un'altra lingua è vicino allo zero (ne parliamo dopo), o quando un mercato specifico emerge dalle tue analitiche:
- Hindi, Indonesiano, Vietnamita, Thailandese — volume di installazioni enorme, ricavo per utente più basso, spesso monetizzato con pubblicità.
- Polacco, Arabo, e le altre lingue regionali che si adattano al tuo pubblico specifico.
Come riferimento rapido:
Adatta il modello alla tua app. Un'app di meditazione con forte retention negli USA e in Germania darà più peso alle lingue europee del Livello 1. Un'app social che insegue la scala salta prima ai mercati di volume del Livello 3. I tuoi dati di installazioni e retention battono qualsiasi lista generica — questi livelli sono il punto di partenza, non il traguardo.
Una scheda può coprire più store
Un'efficienza poco nota ma utile: sull'App Store, una singola localizzazione linguistica serve territori correlati tramite un meccanismo di fallback. Se hai una scheda in francese (Francia) ma non hai impostato il francese (Canada), i metadati in francese (Francia) servono i francofoni canadesi finché non aggiungi la versione specifica. Vale lo stesso per spagnolo (Spagna) e spagnolo (Messico), e così via tra le varianti.
In pratica, questo significa che una sola scheda francese ben scritta raggiunge già i francofoni su diversi store, e una scheda spagnola fa lo stesso tra l'America Latina e la Spagna. Aggiungi la variante specifica per paese più avanti, quando un mercato è abbastanza grande da giustificare l'affinamento di testo e parole chiave. Inizia con la lingua base; affina per territorio quando il volume lo giustifica.
Perché "quante" smette di essere la parte difficile
Ogni livello sopra assume che la traduzione costi qualcosa per lingua — per questo le agenzie ti dicono di essere selettivo. Questa assunzione è il punto in cui Mokbi cambia i conti. Poiché traduce l'intera scheda — il testo dello store e le didascalie degli screenshot — in 50 lingue in un solo passaggio, il costo marginale della ventesima lingua è vicino a quello della seconda.
Quando aggiungere una lingua è quasi gratis, il vincolo si ribalta. Non stai più razionando le traduzioni per proteggere un budget; stai decidendo quali mercati meritano attenzione, parole chiave affinate e, alla fine, un'app tradotta. Questa è una domanda di priorità, e il modello a livelli risponde. Fai la scheda in modo esteso, poi investi in profondità dove i dati indicano.
Gli screenshot sono un passaggio in quel flusso — Screenshot, immagine caratteristica, testo dello store, traduzione, pubblicazione — così le didascalie vengono tradotte nello stesso passaggio della descrizione, ed entrambi restano allineati per locale. Non localizzi il testo in uno strumento e le immagini in un altro.
Una sequenza semplice da seguire
- Localizza la scheda nel Livello 1. Metadati più screenshot, app in inglese sotto. Questo è il tuo test, non un impegno.
- Osserva conversione e retention per mercato. Le installazioni ti dicono se la scheda funziona; la retention ti dice se il mercato è reale.
- Aggiungi il Livello 2, poi il Livello 3. Espandi mentre il costo marginale è basso, e lascia che le tue analitiche facciano salire lingue specifiche nella lista.
- Solo allora traduci l'interfaccia dell'app — per i due o tre mercati che se lo sono guadagnati con retention reale.
Questo ordine mantiene il lavoro costoso (traduzione dell'app) subordinato alle prove, e rende il lavoro economico (una vetrina tradotta) il più ampio possibile in modo utile.