Copy drift: cos’è, cosa lo causa e come prevenirlo

Il copy drift si verifica quando il testo visibile agli utenti si allontana dalla versione approvata tra superfici diverse e nel tempo, senza un’unica fonte di verità da cui allontanarsi. La stringa non manca e non è rotta: è cambiata la formulazione, senza che nessuno decidesse di cambiarla, e ora la pagina marketing, la landing page e il prodotto descrivono la stessa feature in modo leggermente diverso. globalize.now è un sistema di gestione del copy code-native con la localizzazione integrata, ed è proprio il drift il problema specifico che questo sistema serve a prevenire.

Cos'è il copy drift?

Il copy drift si verifica quando il testo visibile agli utenti si allontana dalla versione approvata tra superfici diverse e nel tempo, senza un’unica fonte di verità da cui allontanarsi.

La definizione funziona grazie a due metà. Allontanarsi dalla versione approvata significa che, a un certo punto, qualcuno aveva concordato cosa dovesse dire quella stringa. Nessuna fonte di verità unica significa che non esiste più un artefatto che conservi quell’accordo, quindi non c’è nulla da cui allontanarsi in modo verificabile: ecco perché nessuno sa indicare quando è iniziato.

Il drift è normale, non un’eccezione. Qualsiasi prodotto con più di una superficie e più di una persona che lo modifica sviluppa drift, a meno che qualcosa di strutturale non lo impedisca.

Cosa non è il copy drift

Tre problemi diversi vengono spesso messi nello stesso calderone, ma richiedono correzioni diverse. Confonderli porta i team a inseguire il problema sbagliato.

Una stringa hardcoded è testo scritto direttamente in un componente invece che in un catalogo. È invisibile ai tuoi tool e alla traduzione, ma la formulazione può essere perfettamente corretta. È un problema diverso, che abbiamo trattato in perché i tool di coding basati su IA continuano ad aggiungere stringhe hardcoded.

I file di traduzione fuori sincronia sono cataloghi esistenti che hanno smesso di essere allineati tra loro. La sorgente è corretta; le copie derivate sono obsolete.

Il copy drift è un’altra cosa. La stringa può avere una chiave, i file possono essere sincronizzati e il prodotto può comunque dire «Avvia la prova gratuita» in un punto, «Provalo gratis» in un altro e «Inizia» sul pulsante che esegue davvero l’azione.

Puoi avere tutti e tre i problemi contemporaneamente. Non si risolvono a vicenda.

Cosa causa il copy drift?

Tre meccanismi, indicativamente in ordine di impatto.

Superfici gestite da persone diverse e modificate con tool diversi. Il copy marketing vive in un CMS. La landing page viene aggiornata più rapidamente perché è sottoposta a sperimentazione continua. Le stringhe del prodotto vivono nei componenti. Ogni superficie può essere coerente al proprio interno mentre il prodotto nel suo insieme non lo è, e nessuna singola persona vede tutte e tre le superfici nello stesso momento.

Piccole modifiche che nessuno considera modifiche al copy. Qualcuno accorcia un’etichetta per adattarla a un breakpoint mobile. Qualcun altro mette un heading in sentence case per uniformarlo alla schermata vicina. Prese singolarmente, sono modifiche difendibili. Nessuna passa da qualcosa che assomigli a una revisione del copy, perché per i tool è solo una string literal in un attributo JSX.

Gli agent di coding. A un agent viene chiesto di aggiungere uno stato di caricamento e, mentre lavora sul file, può anche riscrivere un’etichetta: riordinare una stringa gli appare esattamente come riordinare il codice. Finora la risposta della community è stata un file di regole: AGENTS.md, .cursorrules, un blocco di policy sul copy UI nel prompt. Sono utili e vale la pena averli. Ma una convenzione non è un controllo. Riduce la frequenza con cui il copy viene riscritto; non ti dice quando succede comunque.

Perché nessuno rileva il copy drift?

Perché non si rompe nulla.

Un’etichetta modificata compila. Viene renderizzata. Il type checker vede una stringa valida e il linter vede una sintassi valida. Se un test snapshot fallisce, la risposta abituale è aggiornare lo snapshot, che registra il drift invece di segnalarlo. Nessuna build diventa rossa, nessun alert scatta, nessuna dashboard diventa ambra.

Il drift è visibile solo a qualcosa che sa quale fosse la formulazione approvata. La maggior parte dei toolchain non conserva questa informazione, quindi il primo rilevatore è di solito una persona: una risposta del supporto che cita parole diverse da quelle dell’interfaccia, un cliente che chiede se «Workspace» e «Project» siano la stessa cosa oppure un traduttore che domanda quale delle tre formulazioni inglesi debba tradurre.

Quanto costa davvero il copy drift?

A dire il vero, nessuno lo ha misurato, nemmeno noi, e non ci inventeremo una cifra.

Vale la pena dirlo chiaramente, perché questa categoria è piena di numeri che non reggono il confronto con la fonte: dati di sondaggi su branding e ricavi, costi di supporto per ticket, percentuali di ticket attribuiti a documentazione incoerente. Ne abbiamo scartati diversi internamente invece di ripeterli. La misurazione che risponderebbe davvero a questa domanda — quanto drift esiste nelle codebase reali e quali effetti produce a valle — non è stata fatta da nessuno.

Quello che si può descrivere senza un numero è il meccanismo, e il meccanismo è cumulativo:

• È invisibile finché non diventa costoso. Nulla fa emergere il drift quando è ancora economico da correggere. Emerge quando qualcuno ha bisogno che le parole coincidano, di solito sotto pressione.
• Ogni superficie richiede una correzione separata. Cambiare una frase significa trovare ogni punto in cui è stata riscritta, ma non esiste un elenco di quei punti.
• La localizzazione lo moltiplica. Questo è il punto critico. Invia tre formulazioni della stessa idea in traduzione e ottieni tre traduzioni, in ogni lingua. Un’incoerenza contenuta nell’inglese viene ora replicata in tutte le lingue, e per un madrelingua suona come tre funzionalità diverse.

È proprio questo il motivo per cui coerenza del copy e localizzazione non sono progetti separati. Se non puoi dire quale formulazione sia approvata, non puoi tradurne correttamente nessuna: la sorgente era ambigua prima ancora che il traduttore la vedesse. L’architettura che risolve entrambi i problemi è la stessa, come spieghiamo in copy di prodotto code-native.

Come si previene il copy drift?

Dai alle formulazioni un’unica casa e fai in modo che le modifiche siano revisionabili. Il resto viene da sé.

Un catalogo. Ogni stringa visibile agli utenti vive in un unico posto, invece di essere inline nei componenti. Ora esiste qualcosa con cui mantenere la coerenza.

Chiavi, non valori letterali. I componenti fanno riferimento a una chiave invece di riscrivere le parole. La stessa formulazione non può esistere in due punti e divergere in silenzio, perché esiste una sola volta.

Le modifiche nel diff. Una modifica al copy compare in revisione come qualsiasi altra modifica. È questo il passaggio che fa davvero la differenza: la coerenza non dipende più dal fatto che qualcuno ricordi la style guide, ma diventa visibile proprio nel momento in cui qualcuno sta sicuramente guardando.

Le superfici esterne al prodotto — marketing e landing page — sono la metà più difficile, e siamo chiari su dove siamo: standardizzare il copy di marketing, delle landing page e del prodotto in un unico sistema è ciò verso cui stiamo costruendo globalize.now, non qualcosa che puoi attivare oggi. Il meccanismo è lo stesso descritto sopra, esteso oltre il confine dell’app: se ogni superficie fa riferimento alla stringa approvata tramite una chiave invece di riscriverla, cambiare una frase diventa una decisione anziché tre.

I team che rilasciano con tool di coding basati su IA incontrano questo problema per primi. Per questo ne scriviamo per gli sviluppatori e per chi costruisce con tool basati su IA.

Una style guide risolve il copy drift?

No: una style guide e una fonte di verità risolvono problemi diversi, ma i team acquistano regolarmente la prima aspettandosi la seconda.

Una style guide descrive l’aspetto di un buon copy: tono, maiuscole, terminologia, quando usare «delete» e quando «remove». È davvero utile e ogni team dovrebbe averne una. Quello che non può fare è dirti che una stringa è cambiata. Non conserva la formulazione precedente e non si aggancia al momento della modifica, quindi può essere applicata solo da una persona che si trova per caso a guardare la schermata giusta.

Il drift è un problema di stato, non di gusto. La correzione deve vivere dove vive lo stato.

Il drift inizia nel momento in cui le stesse parole esistono in due punti. globalize.now le porta a un’unica fonte nel repository che connetti e deriva ogni lingua da quel copy.