Copy nativa del codice: come il testo dell'interfaccia rimane coerente e pronto per la localizzazione in una codebase

Copy nativa del codice significa che le stringhe visibili all'utente che il tuo prodotto rilascia vivono nel repository come fonte di verità unica, anziché in un file di design che una persona mantiene manualmente allineato. globalize.now è un sistema di gestione della copy nativa del codice con localizzazione integrata: la copy è single-sourced nella codebase e localizzarla è la stessa operazione anziché un handoff separato.

Questo importa più di quanto importasse tre anni fa, perché la copy ha smesso di cambiare solo quando un writer la cambia.

Cos'è la copy nativa del codice?

Copy nativa del codice è un'architettura, non un processo di scrittura: la formulazione approvata e la formulazione rilasciata sono lo stesso artefatto, tenuto nel repository, e ogni modifica arriva come diff.

La distinzione è più facile da vedere in ciò che ogni approccio può osservare. Un prodotto con workspace-of-record tiene la formulazione da qualche parte fuori dal codice e dipende da qualcuno che la spinge dentro, o la tira fuori, quando uno dei due lati si muove. È un buon posto per decidere cosa dovrebbe dire un pulsante. È strutturalmente incapace di notare che il pulsante ora dice qualcos'altro, perché l'evento che lo ha cambiato era un commit e il workspace non ha mai visto il commit.

Un sistema code-native inverte questo. L'unità di lavoro è il diff, e la domanda che può rispondere è quella che effettivamente mette i team nei guai: la stringa è appena cambiata — era previsto?

Niente di questo è un argomento su dove avviene la scrittura. I writer possono scrivere ovunque. È un argomento su quale copy è quella vera quando due non concordano.

Cos'è il copy drift?

Copy drift è il testo visibile all'utente che diverge dalla sua fonte approvata tra le superfici e nel tempo, senza una fonte di verità unica da cui divergere.

Tre fallimenti vengono confusi tra loro e richiedono correzioni diverse:

• Una stringa che non è mai stata associata a una chiave è una stringa hardcoded. È invisibile al tuo catalogo e alla traduzione, ma la formulazione può essere perfettamente corretta. Abbiamo coperto quel pattern in perché gli strumenti di codifica IA continuano ad aggiungere stringhe hardcoded.
• Cataloghi che esistono e si desincronizzano tra loro sono file di traduzione non sincronizzati. La fonte è corretta; le copie derivate sono obsolete.
• Copy drift è nessuno dei due. La stringa è keyata, i file sono sincronizzati, e la formulazione stessa è cambiata senza una decisione — quindi la pagina di marketing promette «Inizia la prova gratuita», la landing page dice «Prova gratis» e il pulsante del prodotto riporta «Inizia».

Il drift è quello costoso perché niente è rotto. Nessuna build fallisce, nessun test diventa rosso, nessuna traduzione manca. Il prodotto semplicemente parla con tre voci e nessuno può indicare il momento in cui è iniziato. Definiamo il termine completamente in copy drift: cos'è, cosa lo causa e come prevenirlo.

Perché gli agenti di codifica IA causano copy drift?

Gli agenti di codifica cambiano la formulazione che non è stato chiesto loro di cambiare, perché riscrivere una stringa vicina è indistinguibile dal riordinare un componente.

Chiedi a un agente di aggiungere uno stato di caricamento e potrebbe anche accorciare un'etichetta, applicare maiuscole iniziali a un titolo o scambiare «Accedi» con «Entra» mentre è nel file. Ogni modifica è difendibile di per sé. Nessuna è stata richiesta e nessuna è contrassegnata come modifica di copy, perché per il tooling è un string literal in un attributo JSX come qualsiasi altro.

La risposta della comunità finora è stata un file di regole — AGENTS.md, .cursorrules, un blocco «UI copy policy» nel prompt. Questi aiutano e vale la pena averli. Ma una convenzione non è un controllo. Riduce la frequenza con cui l'agente riscrive la tua copy; non ti dice quando l'ha fatto.

Dove vive effettivamente la copy del prodotto nella maggior parte dei team?

In quattro posti contemporaneamente, ognuno con un proprietario diverso e un percorso di modifica diverso.

C'è il sito di marketing, di solito in un CMS. C'è la landing page, spesso mantenuta separatamente e aggiornata più velocemente perché è la cosa sotto sperimentazione attiva. Ci sono le stringhe dentro il prodotto, sparse tra i componenti. E ci sono i file di locale, che sono downstream delle stringhe del prodotto e non aggiornati con tutti e tre.

Ognuna di quelle superfici può essere internamente coerente mentre il prodotto nel suo insieme non lo è. Questa è la forma effettiva del problema, ed è perché trattare questo come un problema di product copy da solo non lo descrive completamente.

Come mantieni la copy dell'interfaccia coerente in una codebase?

Rendi il repository la fonte di verità e rendi la stringa un'unità revisionabile — tutto il resto segue da questi due movimenti.

In pratica significa tre cose. Ogni stringa visibile all'utente vive in un catalogo anziché inline nei componenti. I componenti referenziano una chiave anziché un letterale, quindi la stessa formulazione non può esistere in due posti e divergere silenziosamente. E una modifica al catalogo appare nel diff, dove un revisore la vede come vede qualsiasi altra modifica.

Quell'ultimo punto è quello che fa il lavoro. La coerenza della copy è di solito trattata come un problema di disciplina — il team ha bisogno di una guida di stile, qualcuno ha bisogno di ricordare. Una volta che la formulazione è nel diff, smette di dipendere dalla memoria. Diventa visibile al momento della revisione, che è l'unico momento in cui qualcuno sta affidabilmente guardando.

I team che spediscono con strumenti di codifica IA tendono a colpire questo prima e più duramente, ed è per questo che scriviamo al riguardo specificamente per sviluppatori e per persone che costruiscono con strumenti IA.

Perché la coerenza della copy e la localizzazione sono lo stesso problema?

Entrambi falliscono per la stessa ragione: non c'è una fonte concordata con cui essere coerenti o da cui tradurre.

Un team che non può dire quale delle tre formulazioni è quella approvata non può nemmeno localizzare correttamente nessuna di esse. Invia tutte e tre alla traduzione e ottieni tre traduzioni, in ogni lingua, e l'incoerenza è ora moltiplicata dal numero di lingue anziché contenuta in inglese. Questo è il meccanismo dietro la maggior parte di ciò che sembra una scarsa qualità di traduzione — la fonte era già ambigua.

Eseguilo al contrario e i due problemi collassano in uno. Una volta che ogni stringa è single-sourced e keyata, la traduzione è un artefatto derivato di quel catalogo. Non c'è un progetto separato con la sua propria copia della verità, perché c'è solo una copia della verità. Questo è ciò che «localizzazione integrata» significa architetturalmente: non che facciamo anche traduzione, ma che la traduzione è la stessa operazione eseguita sullo stesso oggetto. Abbiamo scritto come questo riordinamento è accaduto in cosa il codice scritto da IA ha fatto alla localizzazione.

E la copy fuori dal prodotto?

Questa è la parte che la categoria non ha risolto, e non pretenderemo il contrario: standardizzare la copy tra marketing, landing page e prodotto come un unico sistema è ciò verso cui stiamo costruendo, non qualcosa che puoi attivare oggi.

Ecco perché è irrisolto. Ogni strumento esistente in questo spazio occupa un ambito specifico. Gli strumenti di product copy gestiscono le stringhe dentro l'app. Le piattaforme di contenuto gestiscono il sito di marketing. Nessuno può vedere l'altro, quindi la formulazione sulla pagina che ha acquisito l'utente e la formulazione sulla schermata che li onboarda sono mantenute da persone diverse in strumenti diversi senza un meccanismo che noterebbe mai che non concordano.

La forma della risposta segue dall'architettura già descritta. Se la formulazione approvata vive in un posto e ogni superficie la referenzia per chiave anziché riformularla, allora la landing page e il pulsante del prodotto sono la stessa stringa, e cambiarla è una decisione anziché tre. Arrivarci è un elemento della roadmap di globalize.now. Nominarlo accuratamente ora sembra meglio che fingere che sia già disponibile.

Come è diverso da uno strumento di copy costruito su un file di design?

La differenza è architettonica piuttosto che categorica — entrambi sono sistemi di gestione della copy e non concordano su dove vive la verità.

Due osservazioni che vale la pena datare, perché lo stato del vendor si muove. A partire dal 2026-08-29, dittowords.com/llms.txt restituisce 404, il che significa che la citazione principale in questa categoria non ha un file di entità leggibile da macchina. E alla stessa data, la pagina del prodotto localize di Ditto descrive l'aggiunta di una variante per ogni lingua e l'anteprima delle traduzioni nei design — non sostiene di produrre le traduzioni. Questo è il punto critico: uno strumento può possedere la formulazione e comunque delegare il lavoro di traduzione a qualcun altro.

Non stiamo nemmeno competendo con i motori di traduzione o le librerie i18n runtime. Questi sono livelli diversi e rimangono dove sono.