Come localizzare un’app generata dall’IA

Questa guida spiega come internazionalizzare e poi localizzare un’app generata dall’IA: chiavi, file di traduzione, estrazione, glossari e automazione che regge anche quando la UI cambia rapidamente. globalize.now è un’infrastruttura di localizzazione basata su IA che mantiene allineati quei cataloghi con Git a ogni push: configuri una volta, sincronizzi automaticamente a ogni push e salti i continui passaggi manuali dei file. Per capire perché le codebase create prima di tutto con l’IA spesso saltano il livello i18n, leggi Il codice IA ha rotto la localizzazione — e nessuno l’ha sistemata. Per il contesto storico degli strumenti, leggi 3 fasi dello sviluppo della localizzazione — e perché l’IA cambia tutto. Per capire come scegliere i vendor quando i repository sono ancora disordinati, leggi globalize.now contro Lokalise contro Crowdin e la guida pratica all’internazionalizzazione Come rendere multilingue la tua app con globalize.now.

---

Cosa significa davvero «localizzare un’app generata dall’IA»?

La localizzazione (l10n) è ciò che vede chi usa l’app: lingua corretta, plurali, date, valuta e layout adatti alla propria locale.

L’internazionalizzazione (i18n) è ciò che fanno prima gli sviluppatori: rendere il testo visibile nell’interfaccia referenziabile, riutilizzabile e sicuro da tradurre su larga scala.

La maggior parte dei blocchi del tipo «non possiamo ancora localizzare» sono in realtà blocchi di i18n. Sistema una volta l’architettura e la localizzazione diventa un problema operativo, non un progetto di archeologia.

---

Cosa deve includere una checklist dell’architettura i18n prima di scegliere gli strumenti?

Prima di scegliere un software per coordinare le traduzioni o un vendor, verifica che esistano questi elementi fondamentali — oppure pianifica di introdurli in quest’ordine:

• Libreria i18n a runtime adatta al tuo stack (React, Next.js, Rails ecc.), con un unico pattern supportato per le stringhe dell’interfaccia.
• Chiavi di traduzione stabili (con namespace e gerarchiche), invece di usare frasi inglesi come ID.
• File di risorse delle lingue (JSON, PO, YAML) versionati nel repository o generati in CI.
• Plurali e variabili in stile ICU per frasi dinamiche come "{count} items", così chi traduce può riordinare la grammatica senza rischi.
• Una pipeline di estrazione delle stringhe, così la nuova UI non aggira il catalogo senza che nessuno se ne accorga.

---

Come si estraggono le stringhe senza rallentare il lavoro?

Le repo generate dall’IA tendono a ripetere le stesse etichette («Salva», «Annulla», «Scopri di più») in decine di file. Il passaggio di estrazione dovrebbe:

1. Rilevare i literal visibili nell’interfaccia nei componenti, nelle route e nei primitive condivisi della UI, ignorando le stringhe tecniche (classi CSS, ID di analytics e URL, a meno che non siano visibili all’utente).
2. Normalizzare i duplicati in un’unica chiave con i relativi riferimenti, così chi traduce vede una sola unità di significato.
3. Generare una locale sorgente (di solito l’inglese) come valore canonico per ogni nuova chiave.
4. Riscrivere i punti di utilizzo per usare l’API i18n concordata dal team, in modo meccanico e con un diff facile da revisionare.

Un esempio minimo di prima e dopo in codice in stile React è questo:

<button>Submit order</button>

Dopo l’estrazione e l’assegnazione delle chiavi:

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

Perché glossari e guide di stile contano prima di scalare il numero di lingue?

La traduzione automatica è veloce. Ma senza vincoli definiti, è facile far sembrare ogni schermata un prodotto diverso. Prima di passare a molte lingue, metti per iscritto:

• I termini del brand che non devono essere tradotti (nome del prodotto, nomi delle funzionalità).
• Le traduzioni preferite per le parole ad alto rischio («contatta», «prova», «fatturazione», «workspace»).
• Il tono: formale o colloquiale, seconda persona o forma neutra.

Inserisci il glossario nel tuo stack di coordinamento o nel profilo MT, così le bozze automatiche restano allineate alle decisioni già prese dal team.

---

Come dovrebbero inserirsi i controlli automatici nel ciclo di QA delle traduzioni?

Quando le chiavi confluiscono nei file di traduzione, il ciclo moderno è: bozza MT → controlli del linter (lunghezza, placeholder, termini vietati) → test di regressione automatici sulle superfici più importanti → rilascio → misurazione. L’automazione fa risparmiare tempo; il linter evita di rilasciare placeholder rotti.

Gli strumenti in stile CLI possono darti rapidamente un quadro del lavoro ancora da fare nella repo, in modo simile a:

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

Quali prompt per agent mantengono revisionabili i refactor di localizzazione?

Questi prompt presuppongono che tu stia lavorando in una repo con test e code review. Sono scritti per produrre diff di cui ti puoi fidare, non refactor estesi e silenziosi.

Come si fa l’inventario delle stringhe della UI prima del refactor?

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

Come si introduce in sicurezza un’API t() tipizzata e minimale?

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

Come si estraggono meccanicamente i literal in chiavi con namespace?

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

Come si prepara un CSV di glossario di cui chi traduce possa fidarsi?

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

Quale guardrail CI impedisce che nuovo inglese hardcoded finisca nel repository?

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

Devi ancora incollare questi prompt a mano?

Sempre meno. Quando questa guida è stata scritta per la prima volta, copiare e incollare i prompt nel proprio agent era il modo pratico per eseguire il ciclo. Da allora gli strumenti si sono spostati dentro l’agent: oggi gli agent di coding possono chiamare direttamente la localizzazione tramite un server MCP, così estrazione, assegnazione delle chiavi e sincronizzazione delle traduzioni diventano chiamate a strumenti eseguite dall’agent, non prompt da incollare. Per la configurazione, leggi Presentazione dell’MCP di globalize.now; per capire perché questo cambiamento conta a livello architetturale, leggi La localizzazione sta diventando una skill per agent, non un SDK.

I prompt qui sopra restano utili come checklist di revisione: descrivono cosa deve fare un buon refactor i18n guidato da un agent, sia che li incolli una persona sia che li codifichi una skill per agent. Valuta ogni refactor automatico con lo stesso criterio: diff revisionabili, chiavi stabili, interpolazione sicura con ICU e un guardrail CI che blocchi le regressioni.

---

Quale vincolo a lungo termine dovresti ricordare quando localizzi prodotti creati con l’IA?

La localizzazione non è un singolo sprint: è un contratto con il tuo futuro. Se investi una volta in chiavi, cataloghi e automazione, ogni nuova schermata generata dall’IA costa meno da rilasciare in tutto il mondo.