Come tradurre i file .po di Drupal con l'IA

La maggior parte delle persone associa i file .po a WordPress, ma il formato gettext precede WordPress di decenni e alimenta la traduzione dell'interfaccia in tutto il mondo open-source. Drupal è uno dei suoi maggiori utilizzatori. Se gestisci un sito Drupal multilingue, ogni etichetta di menu, descrizione di campo, messaggio di errore e stringa di modulo passa attraverso i file .po esattamente come avviene in WordPress, solo con un dialetto di segnaposto e un flusso di lavoro di importazione diversi. E proprio come con WordPress, nel momento in cui il tuo sito supera poche stringhe, la traduzione manuale di quei file diventa il collo di bottiglia.

Questa guida riguarda come tradurre i file po di Drupal con l'IA senza rovinare ciò che rende Drupal, Drupal. Analizzeremo il sistema di traduzione di Drupal, da dove provengono effettivamente le stringhe, la sintassi dei segnaposto che differisce da WordPress e che deve assolutamente essere preservata, e il ciclo completo di esportazione, traduzione e re-importazione, inclusi i comandi drush che lo rendono ripetibile.

Come funziona il sistema di traduzione di Drupal

Drupal gestisce la traduzione dell'interfaccia tramite il modulo core locale (a volte chiamato "Interface Translation" in Drupal moderno). Una volta abilitato, gestisce una tabella del database di stringhe sorgente e le loro traduzioni per lingua, e può importare ed esportare tali traduzioni come file .po standard gettext.

L'interfaccia di amministrazione si trova su /admin/config/regional/translate. Da lì è possibile cercare stringhe non tradotte, modificarle in linea e, cosa fondamentale, importare un file .po per caricare traduzioni in blocco o esportare lo stato corrente in un file .po per la modifica offline. Questo ciclo di esportazione/modifica/importazione è il flusso di lavoro che stiamo ottimizzando.

A differenza di WordPress, dove ogni plugin e tema spedisce i propri file .po e .mo in una directory languages/, Drupal centralizza le stringhe dell'interfaccia nel suo database e tratta .po come formato di interscambio. Si esporta, si lavora sul file e lo si reimporta. Il passaggio .mo compilato che WordPress richiede viene gestito internamente.

Da dove provengono le stringhe

Le stringhe di Drupal provengono da tre fonti, e una traduzione completa deve coprirle tutte:

• Core include migliaia di stringhe traducibili per l'interfaccia utente di amministrazione, i moduli e i messaggi di sistema.
• I moduli Contrib (Views, Webform, Commerce e gli altri) registrano ciascuno le proprie stringhe tramite la funzione t().
• I Temi contribuiscono con stringhe di template, etichette di regione e descrizioni delle impostazioni del tema.

Quando esporti da /admin/config/regional/translate, puoi limitare l'esportazione a stringhe tradotte, non tradotte o tutte. Per un nuovo passaggio di traduzione, esportare solo le stringhe non tradotte ti fornisce un file .po mirato con esattamente il lavoro rimanente.

Una conseguenza pratica di questa struttura a tre fonti: il tuo lavoro di traduzione non è mai veramente "finito". Ogni volta che aggiungi un modulo contrib, abiliti una nuova funzionalità o aggiorni il core di Drupal, un nuovo lotto di voci msgid non tradotte appare nelle tabelle locale. Questo è il motivo per cui i team di Drupal trattano la traduzione come un flusso di lavoro ricorrente piuttosto che un'attività di lancio una tantum. Lo stesso ciclo di esportazione, traduzione e re-importazione viene eseguito ad ogni deployment che tocca i moduli, e più veloce è questo ciclo, minore è il debito di traduzione che si accumula tra una release e l'altra.

Vale anche la pena notare che Drupal può prelevare automaticamente le traduzioni contribute dalla community da localize.drupal.org per il core e i moduli contrib più diffusi. Questi coprono le stringhe comuni, ma raramente coprono i tuoi moduli personalizzati, il tuo tema o la terminologia specifica del progetto che il tuo sito utilizza effettivamente. Il divario tra la traduzione della community e un sito completamente localizzato è esattamente il lavoro che un passaggio AI chiude rapidamente.

I segnaposto di Drupal non sono segnaposto di WordPress

Ecco la cosa più importante da capire prima di inviare qualsiasi file .po di Drupal a un traduttore AI: Drupal non utilizza i segnaposto in stile printf come %s e %1$s che dominano WordPress. La funzione t() di Drupal utilizza tre distinti prefissi di segnaposto, ciascuno con un comportamento di escaping diverso:

• @variable — il valore viene escapato in HTML, il default sicuro per il testo fornito dall'utente.
• %variable — il valore viene escapato e racchiuso in un markup di enfasi <em>.
• :placeholder — utilizzato per gli attributi URL, passato attraverso la sanitizzazione URL.

Una tipica stringa sorgente di Drupal appare così nel file .po esportato:

#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""

#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""

Se un traduttore cambia @count in @cuenta, sostituisce @name con la parola tradotta per "nome" o inserisce uno spazio trasformando @count in @ count, il segnaposto non corrisponde più a ciò che la chiamata t() passa. Drupal quindi stampa il token letterale @count sulla pagina invece del numero effettivo. La traduzione sembra fatta ma il sito è visibilmente rotto.

Questa è la stessa classe di bug che colpisce le stringhe %s di WordPress, e copriamo il principio generale in profondità in come tradurre i file PO senza rompere le variabili di codice. La particolarità di Drupal è semplicemente che ci sono tre stili di segnaposto invece di uno, e uno strumento di traduzione deve riconoscerli tutti.

Perché i traduttori generici falliscono qui

Incolla quella stringa di node.module in una casella di traduzione automatica generica e spesso otterrai @count alterato, il %date racchiuso in <em> localizzato in un token diverso, o le forme plurali accorpate in una sola. Nessuno di questi strumenti è stato costruito pensando alla semantica gettext. Essi traducono il testo; non capiscono che @count è un contratto con il codice dell'applicazione.

Una pipeline di traduzione consapevole di gettext con Syntax Locking tratta @variable, %variable e :placeholder come token immutabili. Vengono bloccati prima della traduzione e ripristinati dopo, in modo che la frase circostante venga tradotta mentre i segnaposto passano inalterati. Lo stesso blocco copre %s e %1$s di WordPress, {{name}} di i18next e l'HTML inline, motivo per cui un singolo strumento può servire un progetto Drupal, Symfony o Laravel con la stessa facilità di uno WordPress. Le forme plurali di Drupal tramite msgid_plural vengono preservate come forme plurali piuttosto che appiattite, il che è importante perché le lingue di Drupal possono avere da una a sei varianti plurali.

C'è anche una modalità di fallimento più sottile che vale la pena di menzionare. Le stringhe di Drupal spesso incorporano markup e link inline all'interno del testo traducibile, come Read the <a href=":url">documentation</a> dove :url è un segnaposto e i tag <a> devono sopravvivere. Un traduttore che non comprende la struttura potrebbe tradurre l'attributo href, eliminare il tag di chiusura o localizzare il nome del segnaposto. Un'IA Consapevole del Contesto che legge l'intera stringa come un'unità, combinata con il blocco dei token, mantiene intatti sia il markup che il contratto :url traducendo solo il testo "documentation" leggibile dall'uomo che si trova in mezzo.

Il ciclo di esportazione, traduzione e re-importazione

Il flusso di lavoro ripetibile ha tre fasi, e drush rende l'esportazione e l'importazione scriptabili in modo da non dover cliccare ogni volta nell'interfaccia utente di amministrazione.

Fase 1: Esportare il file PO

È possibile esportare dall'interfaccia utente all'indirizzo /admin/config/regional/translate scegliendo una lingua e un ambito di esportazione, oppure farlo dalla riga di comando. Il modulo locale espone l'esportazione tramite i servizi di traduzione di Drupal, e la maggior parte dei team lo scripta. Una tipica invocazione di drush per attivare un'importazione di traduzione (l'inverso, che useremo nella fase tre) appare così:

# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
  --type=customized --override=all

# Rebuild caches so the new strings render immediately
drush cache:rebuild

Per quanto riguarda l'esportazione, il modulo di esportazione admin produce il file .po; molti team avvolgono il servizio di esportazione locale in un piccolo comando Drush personalizzato per un'automazione completa. In ogni caso si ottiene un file .po standard gettext contenente le voci msgid non tradotte.

Fase 2: Tradurre il file

Questa è la fase in cui l'IA sostituisce ore di editing manuale. Carica il file .po esportato su un traduttore cloud, scegli la lingua di destinazione e lascialo elaborare. Poiché i file .po di Drupal per un sito grande superano regolarmente i 10MB una volta combinati core, contrib e temi, il Batching Intelligente è importante qui: il file viene suddiviso in blocchi, tradotto e riassemblato senza che tu lo divida a mano o raggiunga i limiti di dimensione. L'output è un file .po completo con ogni msgstr compilato e ogni segnaposto @count, %date e :url esattamente dove era iniziato.

Fase 3: Re-importare in Drupal

Importa il file tradotto tramite /admin/config/regional/translate o tramite il comando drush locale:import mostrato sopra, quindi ricostruisci la cache. Drupal unisce le traduzioni nelle sue tabelle locale, e le stringhe appaiono immediatamente in tutto il sito. Esegui il ciclo di nuovo ogni volta che aggiungi un modulo o aggiorni il core, poiché ognuno porta nuove stringhe non tradotte.

Un dettaglio importante da considerare nell'importazione: il flag --override controlla se le traduzioni in arrivo sostituiscono quelle esistenti. Usa --override=all quando vuoi che il file tradotto dall'IA sia l'autoritativo, o un'impostazione più conservativa se hai modificato manualmente alcune stringhe nell'interfaccia utente di Drupal che non vuoi sovrascrivere. Per la maggior parte delle pipeline automatizzate, trattare il file .po come fonte di verità e sovrascrivere tutto mantiene il sistema prevedibile: il file nel controllo versione è ciò che il sito mostra, punto.

Per i siti multilingue con diverse lingue di destinazione, il ciclo viene eseguito una volta per lingua. Esporta il set non tradotto, traducilo in tedesco, importalo; esporta di nuovo, traducilo in spagnolo, importalo; e così via. Poiché ogni lingua è un file .po indipendente, puoi eseguirli in parallelo, e un traduttore cloud che li elabora contemporaneamente trasforma ciò che prima era una settimana di lavoro di un appaltatore in un pomeriggio.

Drupal PO è uno dei diversi formati

Vale la pena notare che gettext .po non è l'unico modo in cui Drupal gestisce la traduzione. Le entità di configurazione e di contenuto possono anche essere scambiate come XLIFF, che è lo standard su cui si basa il modulo Translation Management Tool (TMGMT) per i flussi di lavoro dei fornitori di traduzione professionali. Se la tua localizzazione Drupal avviene tramite XLIFF piuttosto che tramite file .po dell'interfaccia, i principi di conservazione dei segnaposto sono identici ma la struttura del file differisce, e copriamo questo percorso in tradurre file XLIFF per Drupal, Symfony e Angular.

Per il livello di traduzione dell'interfaccia, tuttavia, .po rimane il cavallo di battaglia. Il ciclo di esportazione, traduzione AI e re-importazione trasforma un'attività manuale di più giorni in pochi minuti di elaborazione, e finché lo strumento che usi comprende veramente i segnaposto gettext, i tuoi contratti @variable sopravvivono intatti e il tuo sito Drupal rimane integro in ogni lingua che pubblichi.

Pronto a tradurre i tuoi file .po di Drupal senza rompere un singolo @variable? Prova SimplePoTranslate gratuitamente — nessuna carta di credito richiesta. Il livello gratuito gestisce i file .po e .pot standard gettext con Syntax Locking completo, in modo che i tuoi segnaposto di Drupal passino esattamente come previsto dal codice.