Le app moderne hanno un problema di localizzazione. E non è la traduzione.
Nell'ultimo decennio, il settore della localizzazione si è concentrato sui flussi di traduzione — strumenti che aiutano i team a gestire i traduttori, revisionare le stringhe e rilasciare contenuti multilingue.
Strumenti come Phrase, Lokalise, Crowdin e Transifex sono eccellenti nella gestione delle traduzioni. Ma danno tutti per scontato qualcosa di critico: che la tua applicazione sia già internazionalizzata. In realtà, la maggior parte delle app non lo è. E con l'ascesa del codice generato dall'IA, quel divario sta per diventare un problema enorme.
Qual è il livello i18n nascosto che gli strumenti di localizzazione non vedono?
Localizzazione e internazionalizzazione vengono spesso confuse. Non sono la stessa cosa.
Localizzazione (l10n) — Tradurre un'app in lingue diverse.
Internazionalizzazione (i18n) — Preparare la codebase affinché la traduzione sia anche solo possibile.
Internazionalizzazione significa cose come: estrarre le stringhe UI, generare chiavi di traduzione, creare file di traduzione, supportare le regole di plurale, formattare numeri e date, supportare le lingue da destra a sinistra ed evitare testo UI hardcoded. La maggior parte degli strumenti di localizzazione entra in gioco dopo questo step. Ma in molte codebase reali, questo step non è mai avvenuto.
Com'è fatto il codice correttamente internazionalizzato
In un'app ben strutturata, il testo UI viene referenziato tramite chiavi di traduzione.
<button>{t("checkout.submit_order")}</button>
Il testo risiede nei file di traduzione:
/locales/en.json
{
"checkout.submit_order": "Submit order"
}
Questa struttura permette agli strumenti e ai motori di traduzione di funzionare in modo affidabile.
Com'è fatta davvero la maggior parte delle app
In realtà, molte app sono fatte così:
<button>Submit order</button>
<h1>Welcome back</h1>
<p>Your payment was successful</p>
A prima vista sembra innocuo. Ma moltiplicalo per centinaia di componenti e migliaia di stringhe UI. Ora l'intera codebase presuppone un'interfaccia solo in inglese. Nel momento in cui provi a supportare un'altra lingua, i problemi iniziano a spuntare ovunque.
- Il testo in tedesco si espande di circa il 30%. I pulsanti traboccano.
- L'arabo richiede layout da destra a sinistra. Intere interfacce si rompono.
- Le regole di plurale variano da lingua a lingua. I messaggi diventano grammaticalmente scorretti.
Senza un'architettura di internazionalizzazione, la localizzazione diventa rapidamente un grosso progetto di refactoring.
In che modo il codice generato dall'IA ha reso la localizzazione più difficile?
Lo sviluppo moderno si affida sempre più a strumenti di coding IA: Cursor, GitHub Copilot, ChatGPT, Replit, Lovable, Bolt. Questi strumenti ottimizzano per la velocità e per un'UI funzionante, non per l'architettura.
Il codice tipicamente generato è fatto così:
<button>Submit</button>
<h2>Welcome back</h2>
<p>Your order has been confirmed</p>
In un tipico progetto generato dall'IA puoi trovare: centinaia o migliaia di stringhe UI hardcoded, testo dell'interfaccia duplicato, nessuna chiave di traduzione, nessun file di traduzione, nessun supporto per il plurale. In altre parole: demo perfette, architettura di localizzazione pessima.
Lo schema è prevedibile. I team costruiscono in fretta, lanciano, guadagnano trazione — e poi si rendono conto: "La nostra intera UI è in inglese hardcoded." A quel punto, aggiungere la localizzazione richiede di toccare gran parte della codebase UI.
Uno schema reale che stiamo osservando
Scansionando piccoli progetti SaaS generati dall'IA, uno schema emerge rapidamente. In un progetto prototipo React che abbiamo analizzato: 1.284 stringhe UI in 312 file, con zero struttura di internazionalizzazione. Gli esempi includevano:
<h1>Welcome back</h1>
<button>Start free trial</button>
<p>Your payment failed</p>
Per aggiungere la localizzazione, il team ha dovuto: estrarre le stringhe UI da centinaia di componenti, introdurre chiavi di traduzione, costruire file di traduzione, riscrivere la logica dell'UI — prima ancora che la traduzione potesse iniziare. Vediamo questo schema ripetersi costantemente nei progetti generati dall'IA.
Perché gli strumenti di localizzazione tradizionali non riescono a gestire il codice generato dall'IA?
La maggior parte degli strumenti di localizzazione è stata progettata per i team di traduzione, non per gli sviluppatori. I loro flussi di lavoro presuppongono che il team di sviluppo abbia già implementato: un framework i18n, chiavi di traduzione, strutture dei file di traduzione, pipeline di estrazione delle stringhe. Ma le codebase moderne — soprattutto quelle generate dall'IA — spesso non hanno affatto queste fondamenta. Così i team si trovano davanti a una realtà inaspettata: prima di poter tradurre qualsiasi cosa, devono rifare da capo l'intero livello UI.
Il livello mancante nello stack di localizzazione
Lo stack di localizzazione tipico di oggi è fatto così:
Ma manca qualcosa di critico. Ciò che deve accadere davvero è:
Quel livello mancante deve: scansionare la codebase, estrarre le stringhe UI, generare chiavi di traduzione, costruire file di traduzione, rilevare le stringhe duplicate, creare glossari terminologici. Solo allora possono iniziare i flussi di traduzione.
Perché questo problema sta per esplodere
Tre grandi tendenze stanno per scontrarsi.
- Sviluppo AI-first. Sempre più app vengono costruite con coding assistito dall'IA. Alcune codebase di startup sono ormai in gran parte generate dall'IA. L'architettura passa spesso in secondo piano rispetto al rilasciare rapidamente.
- Esplosione degli indie hacker. Migliaia di nuovi prodotti SaaS vengono lanciati ogni settimana. La maggior parte parte in inglese.
- Utenti globali fin dal primo giorno. Anche i prodotti piccoli attraggono rapidamente utenti da Germania, Brasile, India, Giappone. Nel momento in cui arrivano utenti internazionali, la localizzazione diventa urgente. Ma l'architettura di solito non è pronta.
Un approccio diverso
E se l'internazionalizzazione potesse essere automatizzata? È esattamente ciò che fa connettere il tuo repository a globalize.now. La prima conversione viene eseguita una volta, nell'app, e restituisce un report di ciò che ha trovato:
✔ Found 128 UI strings
✔ Generated 92 translation keys
✔ Created /locales/en.json
✔ Updated 41 files
Done in 2.7s
Lo strumento farebbe: scansionare la codebase, estrarre le stringhe rivolte all'utente, generare chiavi di traduzione strutturate, creare file di traduzione, riscrivere automaticamente il codice UI. Trasformando questo:
<button>Submit order</button>
In questo:
<button>{t("checkout.submit_order")}</button>
Improvvisamente l'intera codebase diventa pronta per la traduzione.
Una nuova categoria: localizzazione AI-ready
La prossima generazione di strumenti di localizzazione non partirà dai traduttori. Partirà dalla trasformazione del codice. Il flusso di lavoro sarà più simile a questo:
Il gap più grande nell'ecosistema della localizzazione oggi è automatizzare quel primo passaggio: preparare la codebase per gli utenti globali.
Scopri come globalize.now gestisce tutto questo automaticamente per i team di sviluppo.
Per il percorso storico dai tool CAT ai flussi di lavoro AI-native, leggi le tre fasi della localizzazione nell'era dell'IA.
Il futuro della localizzazione
La localizzazione era un problema di traduzione. Nell'era dello sviluppo IA, sta diventando un problema di architettura del codice. I team che risolveranno questo livello definiranno come verrà costruito il software globale nel prossimo decennio.
globalize.now trasforma il testo hardcoded dell'app in file di localizzazione pronti e li mantiene aggiornati mentre rilasci.
Prova globalize.now gratis