i18n senza file di traduzione? Con i18next si può fare, già oggi
« I file di traduzione sono il problema. » È un pitch popolare nel 2026: i tuoi componenti sono la source of truth, quindi basta mantenere a mano JSON per ogni lingua, lascia che il tooling generi le traduzioni e tratta i file di locale come artefatti di build. Un'intera nuova ondata di strumenti i18n è costruita su questo argomento.
La diagnosi è in parte corretta. Modificare a mano diciassette file JSON per aggiungere una frase non diverte nessuno. La parte che il pitch di solito omette: l'ecosistema i18next supporta esattamente questo workflow da anni, con semplici librerie open source, e può fare persino un passo in più, perché con la consegna via CDN nel tuo repository non c'è alcun file di traduzione, nemmeno generato. Ecco la ricetta, seguita dai compromessi onesti.
- Chiavi in linguaggio naturale:
t('Add to cart')conkeySeparator: false; il testo sorgente è la chiave, una traduzione mancante mostra il testo sorgente. Nessun file inglese necessario. - Il rich text resta nel codice: il componente
Transserializza i figli JSX nella chiave, tag indicizzati inclusi. - Le nuove stringhe si traducono da sole:
saveMissingle segnala; la traduzione automatica (la tua chiave LLM o il servizio integrato) riempie tutte le lingue di destinazione; la Quality Estimation valuta ogni risultato. - Zero file, o file come artefatti, a scelta: la consegna CDN a runtime significa zero file di locale nel repository; l'estrazione in CI (
i18next-cli) li produce come artefatti generati se preferisci. - Ciò che « zero file » non risolve: coerenza terminologica, revisione e « chi ha approvato questo? ». I file non sono mai stati il vero problema; l'output non governato sì.
Passo 1: il codice diventa la source of truth
Due righe di configurazione trasformano i18next in un sistema a chiavi in linguaggio naturale:
i18next.init({
keySeparator: false,
nsSeparator: false
})Ora il testo inglese è la chiave:
t('Add to cart')Dietro non c'è alcuna voce en.json. Quando non esiste una traduzione, i18next ricade sulla chiave, e la chiave è il testo sorgente: l'app si renderizza correttamente dal primo secondo. Il rich text funziona allo stesso modo tramite il componente Trans, che serializza i propri figli JSX, markup incluso, nella chiave:
<Trans>Hello <strong>{{name}}</strong>, you have {{count}} unread messages.</Trans>I traduttori vedono Hello <1>{{name}}</1>, you have {{count}} unread messages. e riordinano liberamente il markup per ogni lingua; i tag veri restano di proprietà dei tuoi componenti. I suffissi di plurale e di contesto continuano a funzionare sulle chiavi naturali, perché sono decorazioni della chiave, non file separati.
Passo 2: le nuove stringhe si segnalano da sole
Questo è il pezzo che sostituisce « mantenere i file »: saveMissing. Con saveMissing: true e i18next-locize-backend, ogni stringa che la tua app renderizza per la prima volta viene segnalata automaticamente a Locize, di solito limitato allo sviluppo così la produzione resta in sola lettura:
i18next.init({
saveMissing: process.env.NODE_ENV === 'development'
})Sul lato Locize, la traduzione automatica raccoglie ogni nuova stringa sorgente e riempie tutte le lingue di destinazione, sulla tua chiave OpenAI, Gemini, Mistral o DeepL se ne porti una, con il tuo glossario e la tua styleguide iniettati in ogni richiesta. La Quality Estimation valuta ogni risultato da 0 a 1: le traduzioni sicure vengono salvate direttamente, quelle dubbie passano alla revisione.
Scrivi t('Your trial ends tomorrow'), ricarichi la pagina, e pochi secondi dopo la stringa esiste in ogni lingua, con punteggio. Nessuno ha aperto un file JSON.
Passo 3: consegnare senza file (o con file generati)
A runtime, lo stesso backend carica le traduzioni dal CDN di Locize. Il che significa che la versione più forte di « i file di traduzione sono artefatti di build » esiste anche qui, e di più: nel tuo repository non c'è alcun file di locale. Una correzione pubblicata nell'editor è online senza commit, senza build, senza redeploy.
Preferisci una pipeline statica, o ti servono file per SSR/SSG? Prendi la via CI: i18next-cli estrae le stesse stringhe staticamente (capisce gli scope di t() e serializza i figli di Trans esattamente come react-i18next), e la GitHub Action locize/translate, gratuita, esegue estrazione, sincronizzazione, traduzione automatica e download a ogni push. I file scaricati sono artefatti generati: committali, oppure mettili in gitignore e scaricali in fase di build. La tua app non è ancora strumentata? npx i18next-cli localize la porta dalle stringhe hardcoded alla localizzazione in un solo comando, e npx i18next-cli localize --print-agent-prompt stampa lo stesso flusso come runbook per il tuo agente di coding IA.
I compromessi onesti
Le chiavi in linguaggio naturale sono uno scambio, non un upgrade gratuito, e vale la pena sapere cosa si paga. (Per il quadro decisionale completo sulle strategie di chiavi, incluso quando il content-as-key è la scelta giusta e quando no, vedi la nostra guida alla nomenclatura delle chiavi i18n.)
- Modificare il testo ri-genera la chiave. Cambia « Add to cart » in « Add to basket » ed è una nuova chiave: ritradotta, mentre la vecchia viene rimossa alla sincronizzazione successiva. La translation memory ammortizza il costo, le traduzioni già revisionate tornano come corrispondenze ad alto punteggio, ma per i testi che ruotano ogni settimana le chiavi stabili con
defaultValuerestano lo strumento migliore. i18next permette di mescolare i due stili nello stesso progetto; molti team usano chiavi naturali per i testi UI stabili e chiavi stabili per il copy marketing. - Un testo lungo fa una chiave lunga. Tre paragrafi di note legali come chiave sono sgradevoli in qualunque strumento che mostri le chiavi. Dai a quelle stringhe una chiave stabile e un
defaultValue. - L'ambiguità richiede contesto. L'inglese « Open », verbo o aggettivo, può richiedere due traduzioni diverse. La funzionalità di contesto di i18next (
t('Open', { context: 'button' })) copre il caso, ma l'ambiguità bisogna accorgersene; un workflow centrato sui file non ti protegge di più.
Ciò che « zero file » non risolve
Eliminare la manutenzione dei file elimina una seccatura. Non elimina i problemi davvero difficili della localizzazione, ed è qui che il pitch « il tuo codice è la source of truth » finisce in silenzio: la terminologia che non deve derivare, il registro che non deve capovolgersi a metà app, le stringhe legali che richiedono occhi umani, e la domanda « chi ha approvato questa traduzione? », a cui una pipeline di output bot non revisionato risponde con un hash di commit. Abbiamo documentato cosa si rompe davvero nelle pipeline solo-IA, e nessuna delle modalità di guasto riguarda i formati di file.
Questa è la vera differenza tra i workflow, con o senza file: se l'output tradotto atterra in uno strato governato, con coerenza imposta dal glossario, punteggi di qualità, revisione umana selettiva e cronologia di audit, oppure direttamente in produzione. Input senza chiavi più output non governato è solo deriva più veloce.
Prova l'intero loop in un pomeriggio
Configura le chiavi in linguaggio naturale e saveMissing in un branch, crea un progetto Locize gratuito, attiva la traduzione automatica e guarda le nuove stringhe comparire tradotte e valutate mentre navighi la tua app. Se gestisci già una pipeline IA in CI e ti chiedi in che stato siano i tuoi file di locale, il check di salute i18n gratuito gira interamente nel browser e mostra chiavi mancanti, duplicati e incongruenze di interpolazione prima che tu cambi qualsiasi cosa.
I file di traduzione non sono mai stati il punto. Le traduzioni affidabili in produzione sì, che i file esistano o no.
Stanco di gestire le traduzioni a mano?
Locize è il backend di gestione delle traduzioni creato dal team di i18next: distribuzione via CDN, traduzione con AI, editing in-context, senza nuovi deploy.
Inizia la prova gratuita di 14 giorni