Come Compilare File .po in .mo (4 Metodi)

Hai passato un pomeriggio a perfezionare una traduzione in tedesco. Ogni stringa nel tuo file de_DE.po è perfetta, i placeholder sono intatti, i plurali sono corretti. Lo carichi sul tuo sito, cambi la lingua in tedesco, e... niente. La pagina è ancora in inglese. Ricontrolli il nome del file, la cartella, il text domain. Sembra tutto a posto. Allora perché WordPress non mostra la tua traduzione?

Nove volte su dieci la risposta è la stessa: hai modificato il .po ma non l'hai mai compilato in .mo. WordPress non legge i file .po in fase di esecuzione — carica il .mo binario compilato. Se vuoi che le tue traduzioni appaiano effettivamente, devi compilare po in mo ogni singola volta che modifichi il testo. Il .po è la tua sorgente modificabile; il .mo è ciò che il sito serve.

Questa guida spiega perché esiste questo passaggio di compilazione e poi illustra quattro modi affidabili per farlo: WP-CLI, il classico comando msgfmt, Poedit e uno strumento cloud che produce automaticamente il .mo per te. Tratteremo anche la trappola più comune — dimenticare di ricompilare — e il nuovo formato .l10n.php che WordPress ora preferisce per la velocità.

Perché WordPress Carica .mo e Non .po?

WordPress carica i file .mo perché sono binari compilati ottimizzati per ricerche veloci, mentre i file .po sono testo semplice creato per essere letto e modificato dagli esseri umani. Analizzare il testo ad ogni caricamento della pagina sarebbe lento; leggere una tabella hash binaria pre-costruita è quasi istantaneo.

Un file .po è basato su righe e di facile lettura per l'uomo. Ogni voce associa un msgid sorgente a un msgstr tradotto, oltre a commenti che indicano la provenienza della stringa. Questo è ottimo per la modifica ma terribile per le prestazioni — il server dovrebbe rianalizzare l'intero file di testo ad ogni richiesta.

#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"

Un file .mo raggruppa le stesse coppie di stringhe in un formato binario con una tabella di ricerca interna, così WordPress può passare direttamente a una traduzione senza scansionare il testo. Il compromesso è che il .mo è illeggibile per gli esseri umani e deve essere rigenerato ogni volta che il .po cambia. Se la distinzione tra .po e .mo è ancora poco chiara, la nostra spiegazione su .po vs .mo vs .pot files analizza ogni formato e come si relazionano.

Quattro Modi per Compilare po in mo

Non esiste un unico strumento "corretto" — la scelta migliore dipende da come lavori già. Di seguito sono riportati quattro metodi affidabili, da un comando di una sola riga a un flusso di lavoro cloud completamente automatizzato. Tutti e quattro producono l'identico .mo binario che WordPress carica in fase di esecuzione.

Metodo 1: WP-CLI

L'approccio moderno più pulito è WP-CLI, che può compilare un'intera cartella di file .po con un unico comando. Se gestisci già WordPress dalla riga di comando, questo si adatta naturalmente al tuo flusso di lavoro.

# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/

# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/

Il comando make-mo scansiona la directory di destinazione, compila ogni .po che trova e scrive un .mo corrispondente accanto (o nella destinazione specificata). Gestisce i batch con eleganza, il che lo rende ideale quando si gestiscono molte lingue contemporaneamente. È lo strumento consigliato per qualsiasi progetto che utilizzi già WP-CLI.

Metodo 2: msgfmt

L'utilità Gettext originale per questo compito è msgfmt, parte del pacchetto GNU gettext. Compila un singolo .po in un singolo .mo ed è disponibile praticamente su ogni sistema Linux e macOS.

# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Install it first if missing
#   macOS:  brew install gettext
#   Debian: sudo apt-get install gettext

Il flag -o nomina il file di output. Il flag --statistics è davvero utile — ti dice quante stringhe sono tradotte, fuzzy o ancora vuote, così puoi rilevare una traduzione incompleta prima di distribuirla. Per scriptare un file alla volta, msgfmt è la scelta affidabile e senza fronzoli.

Poiché msgfmt è uno strumento da riga di comando semplice, si inserisce perfettamente nell'automazione. Puoi avvolgerlo in un ciclo shell per compilare un'intera cartella, o collegarlo a una pipeline CI in modo che ogni commit che tocchi un .po produca automaticamente un nuovo .mo. Un pattern comune è for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, che compila ogni lingua in un unico passaggio. Il flag --check aggiunge la convalida, segnalando le mancate corrispondenze delle stringhe di formato tra msgid e msgstr prima che raggiungano la produzione — una salvaguardia economica contro i bug dei placeholder rotti che corrompono silenziosamente i layout tradotti.

Metodo 3: Poedit (Compila al Salvataggio)

Se modifichi le traduzioni in un editor grafico, Poedit compila automaticamente per te. Ogni volta che salvi un file .po, Poedit scrive il .mo corrispondente proprio accanto — nessun comando separato, nessun passaggio aggiuntivo.

Questo è uno dei motivi per cui Poedit rimane popolare tra i traduttori che non si sentono a loro agio con la riga di comando. Apri il .po, digiti le tue traduzioni, premi salva, ed entrambi i file si aggiornano insieme. Puoi confermare il comportamento nelle preferenze di Poedit, dove la compilazione automatica del .mo al salvataggio è abilitata per impostazione predefinita. Poedit e strumenti desktop simili sono recensiti in top 5 free tools to edit and translate PO files on Mac and Windows.

Lo svantaggio di un editor desktop è che la compilazione avviene solo quando un essere umano apre il file e lo salva. Questo va bene per un progetto individuale, ma non si adatta a una dozzina di lingue o a un team che si scambia file. Se qualcuno modifica un .po con uno strumento diverso e lo copia nel repository senza aprire Poedit, il .mo non si aggiorna mai. Per progetti più grandi o collaborativi, un metodo automatizzato — riga di comando o cloud — elimina questa dipendenza dal ricordarsi di premere salva.

Metodo 4: Uno Strumento Cloud Che Genera il .mo per Te

La quarta opzione elimina completamente il passaggio di compilazione: utilizza un servizio cloud che restituisce il .mo compilato insieme al .po tradotto. Non devi mai eseguire un comando o salvare un file due volte — carichi, e tornano file completi, con il nome corretto.

SimplePoTranslate funziona esattamente così. Carichi un .po o un .pot, traduce le stringhe con l'IA Sensibile al Contesto, e restituisce un singolo ZIP contenente il .po e il .mo generati fianco a fianco — già compilati, già nominati per corrispondere al tuo text domain e alla tua locale. Non c'è un passaggio di compilazione separato e nessuna possibilità di dimenticarne uno.

Gestisce anche i dettagli che interrompono i flussi di lavoro manuali. Il Syntax Locking blocca i placeholder come %s, %1$s e {name} più i tag HTML prima della traduzione, così le tue variabili sopravvivono nel .mo intatte. Il supporto completo ai plurali Gettext significa che anche le forme plurali complesse vengono compilate correttamente — un argomento che vale la pena approfondire, che trattiamo in understanding Gettext plurals. E poiché funziona nel cloud, non c'è nessun plugin da installare e nessuno strumento di build da mantenere.

La Trappola Più Comune: Hai Dimenticato di Ricompilare

La ragione principale per cui le traduzioni non appaiono è la modifica del .po ma il dimenticare di ricompilare il .mo. WordPress continua a caricare il vecchio binario, quindi la tua nuova formulazione non appare mai — e non c'è alcun messaggio di errore a dirti il perché.

Il modello mentale da tenere a mente: il .po è la tua bozza, il .mo è ciò che viene distribuito. Qualsiasi modifica al .po è invisibile a WordPress finché non rigeneri il .mo. Rendi la ricompilazione un riflesso dopo ogni modifica, o usa uno strumento che compila automaticamente in modo che il passaggio non possa mai essere saltato.

Questa trappola è particolarmente subdola nei passaggi dallo staging alla produzione. Uno sviluppatore modifica e ricompila localmente, vede la traduzione funzionare, quindi distribuisce solo il .po e dimentica il .mo — così la produzione mantiene silenziosamente il vecchio testo. Ogni volta che sposti i file di traduzione tra ambienti, sposta il .po e il .mo appena compilato insieme, o compila come parte del tuo passaggio di deploy in modo che il binario sia sempre ricostruito dalla sorgente corrente.

Se le tue traduzioni si rifiutano ancora di apparire dopo la ricompilazione, il problema è solitamente una mancata corrispondenza del nome, una cartella sbagliata o un livello di caching che mantiene il vecchio file. La checklist completa si trova in why your translations are not showing up in WordPress.

Una Nota sul Nuovo Formato .l10n.php

Le recenti versioni di WordPress hanno introdotto un terzo formato di runtime: .l10n.php. Invece di un binario .mo, le traduzioni sono memorizzate come un semplice array PHP che la cache dell'opcode PHP può tenere in memoria, rendendo le ricerche ancora più veloci del .mo sui siti trafficati.

<?php
return [
	'domain'  => 'my-plugin',
	'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];

WordPress genera automaticamente i file .l10n.php quando ha a disposizione il .mo corrispondente, quindi non è necessario crearli manualmente. Per ora, la compilazione di un .mo corretto rimane la base — il formato di performance ne deriva.

Riassumendo

Per compilare po in mo in modo affidabile, scegli il metodo che si adatta al tuo modo di lavorare: WP-CLI per batch da riga di comando, msgfmt per file singoli con statistiche, Poedit per la compilazione automatica al salvataggio, o uno strumento cloud che crea il .mo per te in modo che il passaggio non venga mai saltato. Tutti e quattro producono lo stesso binario di cui WordPress ha bisogno in fase di esecuzione.

Qualunque strada tu scelga, ricorda la regola d'oro: modifica il .po, poi compila in .mo — ogni volta. Questa singola abitudine previene il bug di traduzione più frustrante in WordPress, quello in cui tutto sembra giusto ma il sito rimane ostinatamente in inglese.

Pronto a saltare definitivamente il passaggio di compilazione manuale? Prova SimplePoTranslate gratuitamente — nessuna carta di credito richiesta. Carica il tuo .po e scarica un bundle .po + .mo pronto per il deploy con il piano gratuito in pochi minuti.