Avevo un sito WordPress in italiano e inglese. Volevo aggiungere spagnolo, francese e tedesco. Settantadue articoli da tradurre in tre lingue, più pagine di navigazione, categorie, shortcode, redirect, SEO. Guardando il volume di lavoro, la risposta onesta era: non si fa. Non con i tempi e le risorse di un progetto personale. Poi ho usato Claude Code, e in otto sessioni di lavoro distribute su qualche settimana ho completato tutto.

Questo articolo racconta com’è andata davvero: le decisioni, gli errori, le soluzioni, e soprattutto cosa significa collaborare con un agente AI su un progetto di scala reale. Non è una guida tecnica passo-passo — è il racconto di un’esperienza, con abbastanza dettagli pratici da permetterti di replicarla.

La frustrazione di partenza

Il problema con l’internazionalizzazione di un sito WordPress non è la traduzione. È la complessità sistemica che sta intorno alla traduzione.

Con Polylang — il plugin che uso per gestire le lingue — ogni lingua non è solo un’etichetta sul testo. È un set separato di post, pagine, categorie con ID distinti, URL con prefisso diverso, shortcode da aggiornare, redirect da configurare. Tradurre un articolo manualmente significa: creare il post nella nuova lingua, collegarlo all’originale, assegnargli le categorie nella versione della nuova lingua (non quelle italiane — quelle tedesche, con ID diversi), copiare la featured image, impostare la data giusta, compilare i campi SEO. Per ogni articolo. Per settantadue articoli. Per tre lingue.

Ho guardato le alternative. I plugin di traduzione automatica (WPML + DeepL, TranslatePress) traducono il testo ma non capiscono la struttura — i blocchi Gutenberg con ID di categoria hardcoded rimangono sbagliati, gli shortcode custom non vengono toccati, la configurazione tecnica è a carico tuo comunque. Un’agenzia di localizzazione avrebbe gestito la traduzione ma non la parte tecnica WordPress. Uno sviluppatore freelance avrebbe gestito la parte tecnica ma non la traduzione. La combinazione delle due cose, per settantadue articoli in tre lingue, era un progetto da mesi e da migliaia di euro.

Quindi il progetto era rimasto fermo. Come rimangono fermi la maggior parte dei progetti ambiziosi su siti personali: non per mancanza di intenzione, ma per mancanza di tempo e risorse.

La prima sessione: capire cosa poteva fare Claude Code

Claude Code non è un chatbot a cui fare domande. È un agente con accesso agli strumenti del sistema: può leggere e scrivere file, eseguire comandi nel terminale, interrogare database, modificare codice. Quando gli ho descritto il problema — sito WordPress, plugin Polylang, settantadue articoli, tre lingue da aggiungere — non ha risposto con una lista di istruzioni da seguire. Ha iniziato a lavorare.

Ha letto il codice del mu-plugin custom che gestisce la navigazione del sito. Ha interrogato il database per capire come Polylang organizza le traduzioni internamente. Ha identificato i sette punti del plugin da aggiornare per supportare una nuova lingua. Tutto questo senza che io gli spiegassi come funziona Polylang — lo ha capito leggendo il codice sorgente e le strutture del database.

Il mio ruolo in quella prima sessione era diverso da quello che mi aspettavo. Non stavo dando istruzioni tecniche. Stavo prendendo decisioni: aggiungiamo il tedesco o il cinese? Iniziamo dallo spagnolo o dal francese? Priorità alla struttura di navigazione o agli articoli? Le decisioni strategiche erano mie. L’esecuzione tecnica era di Claude Code.

Come si è evoluta la collaborazione

Dopo la prima sessione ho capito qual era il pattern di collaborazione che funzionava meglio:

• Io portavo il contesto e le priorità: “questa settimana voglio completare il francese”, “prima le pagine di navigazione poi gli articoli”, “il tedesco è più importante del portoghese perché il DACH è un mercato rilevante”
• Claude Code portava il piano e l’esecuzione: proponeva l’approccio, lo eseguiva, mostrava l’output, segnalava i problemi, correggeva autonomamente quando qualcosa non funzionava
• Io validavo il risultato: aprire il sito nella nuova lingua, verificare che un articolo avesse l’immagine giusta, le categorie corrette, la data originale

Non serviva background tecnico su Polylang, WP-CLI o PHP. Serviva sapere cosa volevo ottenere e saper riconoscere se il risultato era corretto.

Il problema delle sessioni multiple e la memoria

Un progetto di questa scala — settantadue articoli per lingua — non si completa in una sessione. Claude Code ha un limite di contesto: a un certo punto la conversazione diventa troppo lunga e si deve ricominciare. Il rischio è che ogni sessione nuova riparta da zero, ri-esplorando cose già scoperte, ripetendo errori già risolti.

La soluzione è il sistema di memoria persistente integrato in Claude Code: file di testo salvati in una directory specifica che vengono caricati automaticamente all’inizio di ogni nuova sessione. Abbiamo usato questo sistema per salvare:

• La checklist completa dei passi per aggiungere una lingua (in ordine, con le insidie di ognuno)
• La mappatura di tutte le categorie italiano → lingua target
• Gli errori già incontrati e i fix applicati
• Lo stato del progetto: quali batch erano stati completati, quanti articoli mancavano

Con questi file di memoria, ogni sessione nuova riprendeva esattamente da dove si era fermata. Il “costo di avvio” di una sessione si riduceva a pochi minuti invece che a ore di ri-esplorazione.

Questo è uno degli aspetti meno ovvi di Claude Code: non è solo uno strumento per fare cose, ma anche per costruire conoscenza persistente su un progetto nel tempo.

La pipeline tecnica che ha funzionato

Per chi vuole capire il lato tecnico: il cuore del processo era una pipeline in tre fasi.

Claude Code scriveva le traduzioni degli articoli e i metadati in un file JSON standard. Questo file veniva poi letto da uno script PHP eseguito direttamente nel contesto WordPress tramite WP-CLI. Lo script PHP creava ogni articolo nella nuova lingua, lo collegava all’originale italiano, assegnava le categorie nella versione della nuova lingua, copiava l’immagine, impostava la data e compilava i campi SEO.

Ogni batch elaborava dieci articoli. Per settantadue articoli: sette o otto batch. Ogni batch produceva un output leggibile — “OK IT:123 → DE:456 | Titolo articolo” — che permetteva di verificare immediatamente cosa era andato e cosa no.

La scelta del formato JSON come ponte tra la generazione AI e l’esecuzione WordPress non era ovvia all’inizio — il primo approccio usava un formato diverso che produceva errori di parsing. Ma una volta stabilita la pipeline corretta, ha funzionato in modo affidabile per tutti i batch successivi.

Gli errori: cosa è andato storto e come è stato risolto

Raccontare solo i successi sarebbe disonesto. Ecco gli errori reali che abbiamo incontrato.

Il primo approccio di trasferimento dati non funzionava

Il tentativo iniziale era generare codice PHP direttamente dal codice Python usato per preparare i dati. Il risultato erano errori di parsing immediati: i due linguaggi hanno convenzioni diverse per rappresentare strutture dati, e mescolarli produceva codice invalido. Fix: separare i formati. Python scrive JSON standard, PHP legge con le sue funzioni native. Il JSON è un formato di scambio dati esplicito — funziona sempre tra sistemi diversi.

Le categorie degli articoli erano nella lingua sbagliata

Polylang crea un set separato di identificatori numerici per ogni lingua. La categoria “Tecnologia” in italiano ha un numero. In tedesco ha un numero diverso. Se assegni il numero italiano a un articolo tedesco, gli stai assegnando la categoria italiana — e le griglie di articoli mostrano contenuto misto o vuoto. Questo errore non era visibile nell’output dello script, solo aprendo il sito nella nuova lingua. Da qui la regola: validare sempre dopo il primo batch, non alla fine di tutti.

Una categoria tedesca puntava a “Uncategorized”

Quando abbiamo aggiunto il tedesco, una delle categorie era già collegata nel database di Polylang a un termine generico creato automaticamente, non alla categoria reale. Claude Code ha trovato l’anomalia interrogando il database, ha creato la categoria corretta e aggiornato il collegamento. Senza la possibilità di interrogare direttamente il database, questo tipo di problema sarebbe stato invisibile fino a molto più tardi.

I post venivano creati senza immagine e con la data sbagliata

La funzione di Polylang che crea post in una nuova lingua non copia automaticamente la featured image né la data di pubblicazione originale. Gli articoli apparivano senza immagine e datati al giorno della creazione invece che alla data originale. Fix: aggiungere esplicitamente nello script PHP la copia dell’immagine e la data per ogni articolo creato.

La qualità delle traduzioni

La domanda più comune: quanto è buona la traduzione generata dall’AI?

Per contenuto tecnico — articoli su Linux, database, strumenti di sviluppo, Raspberry Pi — la qualità è molto buona. La terminologia è corretta, i comandi rimangono invariati, le spiegazioni sono coerenti. Un lettore tedesco che legge un articolo su Ansible o su SQL Server non si accorge che è stato generato da un’AI.

Per contenuto più editoriale — recensioni di videogiochi, riflessioni personali, articoli di opinione — la qualità è buona ma con un tono leggermente più formale di quanto sarebbe un testo scritto nativamente. Non è traduzione letterale: Claude Code adatta il contenuto al contesto della lingua target. Un articolo su Cyberpunk 2077 scritto con un certo registro colloquiale in italiano diventa in tedesco qualcosa di stilisticamente appropriato per il pubblico tedesco, non una trasposizione parola per parola.

La soglia utile da tenere in mente: la qualità è abbondantemente sufficiente per portare contenuto di valore a lettori in lingue diverse. Non è identica a una traduzione professionale umana. Ma è enormemente meglio di non avere nulla — che era esattamente la situazione di partenza.

Perché questo approccio è diverso da un traduttore automatico

Un traduttore automatico (DeepL, Google Translate) fa una cosa sola: converte il testo da una lingua all’altra. Non tocca la struttura del sito, non aggiorna il plugin di navigazione, non crea le categorie nella nuova lingua, non configura i redirect, non compila i campi SEO.

Claude Code come agente fa tutto questo insieme. Non perché sia “più intelligente” in senso astratto, ma perché ha accesso agli strumenti del sistema e può agire su di essi. La differenza pratica è enorme: un traduttore automatico ti dà del testo tradotto da incollare. Claude Code ti dà un sito funzionante in una nuova lingua.

C’è anche una differenza qualitativa nella traduzione stessa. Un traduttore automatico applica regole linguistiche. Claude Code capisce il contesto: sa che un articolo è una recensione di un videogioco, che il pubblico è appassionato di tecnologia, che il tono deve essere informale ma preciso. La traduzione risultante è più coerente con l’intenzione originale dell’articolo.

Il bilancio finale

Settantadue articoli per cinque lingue. Quarantacinque pagine di navigazione. Cinquecentoquaranta campi SEO. Decine di aggiornamenti al codice del plugin. Tutto completato in sessioni di lavoro distribuite su qualche settimana, senza un team, senza un budget significativo, senza background tecnico specializzato su Polylang o WP-CLI.

Il numero che però conta di più è uno solo: zero. Zero articoli in spagnolo, francese e tedesco che ci sarebbero stati senza questo approccio. Il progetto sarebbe rimasto nella lista delle cose da fare, come ci era rimasto per mesi.

Questo è il vero vantaggio di lavorare con un agente AI su progetti di scala: non che sia più veloce (lo è), non che costi meno (lo fa), ma che rende fattibili progetti che altrimenti non verrebbero mai fatti. Abbassa la soglia di accesso a un livello in cui un singolo proprietario di sito può fare cose che prima richiedevano un team.

Cosa serve per iniziare

Se vuoi replicare questo approccio sul tuo sito WordPress multilingua, il punto di partenza pratico:

• Claude Code — la CLI di Anthropic, disponibile su claude.ai/code. Richiede accesso al terminale del server dove gira il tuo WordPress
• WP-CLI — installato sul server, permette a Claude Code di interagire con WordPress da riga di comando
• Polylang — il plugin gratuito funziona. Pro aggiunge alcune comodità ma non è necessario
• Un documento di contesto iniziale — prima di iniziare, scrivi (o fai scrivere a Claude Code) un documento che descrive la struttura del tuo sito, i plugin usati, come funziona la navigazione. Questo riduce drasticamente il tempo di “warm-up” di ogni sessione

La cosa meno ovvia: il tuo ruolo non è dare istruzioni tecniche. È sapere cosa vuoi ottenere, approvare i piani proposti, e validare i risultati. Le competenze tecniche le porta Claude Code.

---