Controlla sette cose prima di rilasciare un'app tradotta con un solo prompt da Codex, Claude Code o Cursor: se le stringhe lunghe ci stanno, se le forme plurali corrispondono a ciascuna lingua, se le variabili sono sopravvissute, se i termini restano coerenti, se il tono suona giusto a un madrelingua, se ogni chiave esiste in ogni locale e se la prossima feature verrà tradotta. globalize.now è un'infrastruttura di localizzazione basata su IA, e la maggior parte di ciò che vediamo andare storto dopo una traduzione one-shot è meccanica, ed è una buona notizia: i problemi meccanici si possono verificare.

Il primo passaggio raramente è il problema. Gli agent moderni producono traduzioni leggibili in fretta. Quello che un singolo prompt non include è un passaggio che verifichi l'output, e questi controlli sono proprio quel passaggio.

Il testo ci sta dopo la traduzione?

Spesso no, e i button sono i primi a cedere. Le linee guida del W3C sulla dimensione del testo nella traduzione osservano che più il messaggio sorgente è breve, maggiore è l'espansione probabile: una label di due parole cresce quindi in proporzione più di un paragrafo. Segnalano anche che i nomi composti in lingue come il tedesco possono non andare a capo, e che alcuni sistemi di scrittura richiedono più spazio, in orizzontale o in verticale, rispetto al testo latino.

Un agent che traduce le stringhe in un file JSON non vede mai lo schermo, quindi non può sapere che «Salva modifiche» ora riempie il button da un bordo all'altro. Avvia l'app nel locale più lungo che rilasci, percorri i flussi principali e cerca testo tagliato, button che vanno a capo e intestazioni di tabella troncate. Se supporti le lingue RTL, fai lo stesso giro in una di queste; la guida ad arabo e RTL per le app Lovable tratta la direzione, che i controlli di overflow da soli non coprono.

La soluzione duratura è nel layout, non nell'accorciare le traduzioni: lascia crescere i contenitori, evita larghezze fisse sul testo e smetti di abbreviare per farcelo stare. Delega questa parte al tuo agent, perché è codice.

Le forme plurali corrispondono alla lingua di destinazione?

Controllalo presto, perché fallisce in silenzio. Unicode CLDR definisce sei categorie di plurale: zero, one, two, few, many e other. L'inglese ne usa solo due, one e other. Il russo usa one, few, many e other. Il gallese le usa tutte e sei, e la documentazione di i18next mostra anche l'arabo con tutte e sei le chiavi di plurale.

Un agent che copia la coppia inglese in un file russo o arabo produce un catalogo che viene parsato e renderizzato, e mostra la forma sbagliata per ogni numero che richiede una categoria assente dal file. Non genererà alcun errore. Con i18next ricorda che la variabile deve chiamarsi esattamente count, e la documentazione precisa che, se manca, non c'è alcun fallback alla chiave semplice. Lo stesso agent che scrive count === 1 ? 'item' : 'items' in un componente ha lo stesso bug prima ancora che la traduzione inizi; cos'è ICU MessageFormat e perché fa inciampare le app generate dall'IA copre il lato sintassi.

Il controllo è meccanico: per ogni locale, confronta le chiavi di plurale con le categorie richieste da quella lingua.

Le variabili di interpolazione sono sopravvissute?

Non sempre, e uno script lo chiarisce. Le variabili di interpolazione come {{name}} o {count} devono comparire in ogni traduzione esattamente come scritte. Gli agent che traducono un file lungo a volte riformulano una variabile, ne eliminano una perché la frase scorre meglio senza, o traducono il contenuto di un tag. Il risultato è uno spazio vuoto, una graffa letterale o un crash.

Confronta l'insieme di variabili di ogni stringa tradotta con quello della stringa sorgente. Questo breve script Node lo fa e segnala anche le chiavi presenti in inglese ma assenti in un altro locale:

import fs from "node:fs";

const [src, ...targets] = process.argv.slice(2);
const read = (f) => JSON.parse(fs.readFileSync(f, "utf8"));
const vars = (s) =>
  [...String(s).matchAll(/\{\{?\s*[\w.]+\s*\}?\}/g)].map((m) => m[0]).sort().join(",");

const base = read(src);
let problems = 0;
for (const file of targets) {
  const loc = read(file);
  for (const [key, text] of Object.entries(base)) {
    if (!(key in loc)) { console.log(file, "missing", key); problems++; continue; }
    if (typeof text === "string" && vars(text) !== vars(loc[key])) {
      console.log(file, "variable mismatch", key); problems++;
    }
  }
}
process.exit(problems ? 1 : 0);

Eseguilo come node check-locales.mjs locales/en.json locales/de.json locales/ru.json in CI. Presuppone file di chiavi a un solo livello; adatta il ciclo se il tuo catalogo è annidato.

La terminologia è coerente?

Lo è dentro una singola risposta e va alla deriva su più risposte. Se la traduzione di una grande app è divisa tra file, sessioni o batch, nulla garantisce che «workspace», «progetto» e il nome del tuo prodotto escano uguali ogni volta. Finisci con un button che dice una cosa e una pagina di aiuto che ne dice un'altra.

Scrivi i termini una volta sola: un glossario con nomi di prodotto, nomi di feature e parole da non tradurre, e fai in modo che il passaggio di traduzione lo legga. globalize.now genera un glossario condiviso quando converte la codebase, così i termini esistono come dati prima che inizi qualsiasi traduzione. Senza uno strumento, il minimo è un breve file di glossario richiamato dalle istruzioni del tuo agent; il post sulle regole di AGENTS.md mostra dove vivono quelle istruzioni.

Suona bene a un madrelingua?

È l'unico controllo che uno script non può fare. Registro, formalità e maiuscole sono i punti in cui le traduzioni one-shot tradiscono la mano della macchina: il livello sbagliato di cortesia, button all'imperativo che suonano come ordini, un titolo tutto in maiuscolo in una lingua in cui equivale a gridare.

Non rivedere ogni stringa. Scegli una lingua per ogni famiglia linguistica che rilasci e chiedi a un madrelingua di leggere le schermate di primo avvio, il flusso di checkout o di registrazione e i messaggi di errore. Sono le schermate in cui il tono ti costa utenti. Annota le correzioni del madrelingua nel glossario, così il passaggio successivo parte da lì.

Ogni chiave esiste e ogni stringa è finita nel catalogo?

Due lacune diverse sembrano identiche a schermo. Una chiave può esistere in inglese e mancare in un locale, cosa che lo script qui sopra intercetta. Oppure una stringa può essere rimasta hardcoded nel componente, senza mai arrivare al catalogo, e nessuna traduzione potrebbe coprirla. Gli agent lasciano la seconda categoria negli attributi, nei toast e nei messaggi di errore più spesso che nel testo visibile; perché gli agent continuano ad aggiungere stringhe hardcoded tratta il pattern e la regola di lint che lo intercetta.

Porta l'app su un locale non inglese e naviga tra le schermate. Ogni residuo in inglese è una chiave mancante o una stringa che non è mai entrata nel sistema, e la soluzione cambia.

La prossima feature verrà tradotta?

Solo se la traduzione fa parte di come il codice viene rilasciato, ed è il controllo che un'esecuzione con un solo prompt non può superare. Il prompt ha tradotto l'app com'era quel pomeriggio. La prossima feature che il tuo agent costruisce arriva in inglese, negli stessi file, e le lingue localizzate restano indietro una feature alla volta. Perché i file di traduzione vanno fuori sincronia descrive come si accumula il problema.

Qui l'approccio one-shot e una pipeline si separano. La localizzazione che si sposta a monte, nel ciclo di sviluppo espone la tesi; la versione pratica è che la conversione avviene una volta e le modifiche successive vengono tradotte dove si fanno. Con globalize.now colleghi il repository nell'app, la codebase viene convertita una volta sola e poi i job di push traducono le nuove unità del catalogo, con i risultati consegnati come modifiche da rivedere e fare il merge. La libreria di runtime e il formato del catalogo restano tuoi. I team che hanno già un traduttore umano mantengono quel passaggio di revisione, che semplicemente smette di essere l'unica barriera tra il codice solo in inglese e un rilascio.

Se preferisci tenere tutto nei tuoi script, il minimo è lo script qui sopra in CI più una regola per cui le nuove stringhe passano dal catalogo. Come localizzare un'app generata dall'IA percorre l'intero iter, e la guida a Claude Code copre nello specifico quell'agent.

Da dove si parte?

Esegui lo script sui tuoi file di locale oggi stesso: ci vuole un minuto e ti dice se la struttura regge. Poi apri l'app nel locale più lungo e percorri il flusso di primo avvio. Se hai rilasciato un'app creata con l'IA e vuoi che conversione, traduzione e aggiornamenti successivi siano gestiti e non mantenuti a mano, la pagina per i vibe coder è la panoramica, il riferimento per sviluppatori copre le configurazioni degli agent, e i prezzi hanno una pagina a parte.

globalize.now trasforma il testo hardcoded dell'app in file di localizzazione pronti e li mantiene aggiornati mentre rilasci.

Prova globalize.now gratis