Perché i contenuti multilingua dovrebbero stare su git

La maggior parte dei siti multilingua finisce per avere tre fonti di verità: i contenuti in un CMS in hosting, le traduzioni in una piattaforma dedicata e il codice su git. Ognuna ha il proprio sistema di versioning, il proprio controllo degli accessi e la propria idea di cosa significhi "attuale". Mantenerle sincronizzate è un lavoro a tempo pieno e il disallineamento è la normalità. Esiste un modello più semplice: mettere tutto nella repository. ## I problemi che git ha già risolto Il tuo flusso di lavoro del codice gestisce già le complessità del content management: - Revisione. Una modifica ai contenuti equivale a una pull request. Qualcuno legge le differenze prima della pubblicazione. - Rollback. Un errore di redazione si risolve con un revert, non con un ticket di assistenza. - Atomicità. I contenuti e il codice che li visualizza vengono distribuiti insieme. Una modifica allo schema e la relativa migrazione dei contenuti avvengono con un unico commit. - Cronologia. Il comando git log permette di sapere chi ha modificato cosa e quando, senza bisogno di plugin. Un CMS basato su file ottiene tutto questo gratuitamente. Il problema sorge quando si moltiplica ogni pagina per dieci lingue. ## Il problema della traduzione L'approccio più ingenuo prevede un file per lingua: about.en.mdx, about.fr.mdx, about.ja.mdx. Ma si rivela subito fallimentare. Con dieci lingue, un sito di 50 pagine si trasforma in 500 file, la revisione diventa impossibile per le lingue che nessuno del team conosce e non c'è modo di sapere se about.fr.mdx rispecchi il testo inglese attuale o la versione di tre mesi fa. Scribe separa i due aspetti: - I contenuti in inglese sono file MDX. Un file per ogni documento, validato tramite uno schema Zod. Questa è la parte scritta e revisionata dalle persone. - Le traduzioni risiedono in un unico file SQLite, committato accanto ad essi. Ogni traduzione è collegata a un hash della sua origine inglese, insieme a un'istantanea di come appariva quel testo. L'hash è ciò che elimina il disallineamento. Se modifichi un paragrafo in inglese, esattamente un documento diventa obsoleto in ogni lingua, ed è visibile a tutti. Eseguendo scribe translate verrà ritradotto solo quel documento. Nessun file rimane indietro in modo invisibile e il comando scribe status mostra la copertura esatta a ogni commit. ## Nessun server, per natura Poiché tutto è gestito tramite file nella repository, non c'è nulla da ospitare. A tempo di compilazione, il runtime legge i file MDX e SQLite dal disco e fornisce al framework documenti completamente tipizzati: elenchi, lookup, relazioni, tag hreflang e voci della sitemap. Non ci sono API del CMS da richiamare al momento della richiesta, nessun token da ruotare e nessun disservizio del fornitore che possa rendere inaccessibili i tuoi contenuti. Consulta le API del runtime per scoprire come funzionano le letture. ## I file sono l'ambiente ideale per gli agenti IA C'è un'argomentazione ancora più recente a favore di questo modello, e forse è la più forte: gli agenti IA danno il meglio con le repository. Un agente di programmazione sa già come cercare tra i file, leggere gli MDX come testo normale, modificarli su un branch e aprire una pull request. Se lo indirizzi verso un CMS in hosting, invece, ti ritroverai a configurare API, token e integrazioni personalizzate prima ancora che riesca a cambiare un titolo. Anche le misure di sicurezza rimangono valide. Il frontmatter viene validato in base allo schema Zod e ogni body deve essere compilato correttamente come MDX, quindi un agente non può salvare un documento malformato; scribe validate rileva l'errore prima della build. E dato che ogni modifica è un commit, gli interventi dell'IA ricevono lo stesso trattamento di quelli umani: diff, revisione, approvazione. Questo sito funziona esattamente in questo modo; la maggior parte della manutenzione della documentazione e del changelog è affidata agli agenti, mentre gli esseri umani revisionano le differenze. ## Quando questo modello non fa per te Parliamo chiaro. Un CMS basato su git presuppone che chi redige i contenuti abbia dimestichezza con file e pull request, oppure che una figura tecnica faccia da tramite con la repository. Se i tuoi editor hanno bisogno di un'interfaccia WYSIWYG e di un pulsante di pubblicazione, un CMS in hosting è la scelta giusta. Scribe include uno studio locale per esplorare, cercare e ispezionare le traduzioni, ma la scrittura avviene direttamente nel tuo editor. Tuttavia, se il tuo team lavora già su git, aggiungere un secondo e un terzo sistema per i contenuti e le traduzioni non farà che aumentare la complessità. Una repository, un flusso di revisione, un unico deploy. ## Provalo L'intera configurazione si riduce a un file di configurazione e una cartella di file MDX: bash pnpm add scribe-cms zod better-sqlite3 Inizia con la guida introduttiva, oppure scopri come funziona la traduzione dietro le quinte.