Hur man kompilerar .po till .mo-filer (4 metoder)

Du tillbringade en eftermiddag med att perfektionera en tysk översättning. Varje sträng i din de_DE.po-fil läser vackert, platshållarna är intakta, pluralformerna är korrekta. Du laddar upp den till din webbplats, byter språk till tyska, och... ingenting. Sidan är fortfarande på engelska. Du dubbelkollar filnamnet, mappen, textdomänen. Allt ser rätt ut. Så varför visar WordPress inte din översättning?

Nio gånger av tio är svaret detsamma: du redigerade .po men kompilerade den aldrig till .mo. WordPress läser inte .po-filer vid körning — det laddar den kompilerade binära .mo. Om du vill att dina översättningar faktiskt ska visas, måste du kompilera po till mo varje gång du ändrar texten. .po är din redigerbara källa; .mo är vad webbplatsen visar.

Denna guide förklarar varför detta kompileringssteg existerar och går sedan igenom fyra pålitliga sätt att göra det: WP-CLI, det klassiska kommandot msgfmt, Poedit, och ett molnverktyg som automatiskt producerar .mo åt dig. Vi kommer också att täcka den vanligaste fallgropen — att glömma att kompilera om — och det nyare .l10n.php-formatet som WordPress nu föredrar för snabbhet.

Varför laddar WordPress .mo och inte .po?

WordPress laddar .mo-filer eftersom de är kompilerade binära filer optimerade för snabba uppslagningar, medan .po-filer är oformaterad text avsedd för människor att läsa och redigera. Att tolka text vid varje sidladdning skulle vara långsamt; att läsa en förbyggd binär hashtabell är nästan omedelbart.

En .po-fil är radbaserad och användarvänlig. Varje post parar ihop en käll-msgid med en översatt msgstr, plus kommentarer som anger var strängen kom ifrån. Det är utmärkt för redigering men fruktansvärt för prestanda — servern skulle behöva tolka om hela textfilen vid varje förfrågan.

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

En .mo-fil packar samma strängpar i ett binärt format med en intern uppslagningstabell, så att WordPress kan hoppa direkt till en översättning utan att skanna text. Kompromissen är att .mo är oläsligt för människor och måste återskapas när .po ändras. Om skillnaden mellan .po och .mo fortfarande är oklar, förklarar vår guide om .po vs .mo vs .pot-filer varje format och hur de relaterar.

Fyra sätt att kompilera po till mo

Det finns inget enskilt "korrekt" verktyg — det bästa valet beror på hur du redan arbetar. Nedan finns fyra pålitliga metoder, från ett enradskommando till ett helt automatiserat molnarbetsflöde. Alla fyra producerar den identiska binära .mo som WordPress laddar vid körning.

Metod 1: WP-CLI

Den renaste moderna metoden är WP-CLI, som kan kompilera en hel mapp med .po-filer i ett enda kommando. Om du redan hanterar WordPress från kommandoraden passar detta naturligt in i ditt arbetsflöde.

# 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/

Kommandot make-mo skannar målkatalogen, kompilerar varje .po det hittar och skriver en matchande .mo bredvid den (eller till den destination du anger). Det hanterar batchar elegant, vilket gör det idealiskt när du underhåller många språk samtidigt. Det är det rekommenderade verktyget för alla projekt som redan använder WP-CLI.

Metod 2: msgfmt

Det ursprungliga Gettext-verktyget för denna uppgift är msgfmt, en del av GNU gettext-paketet. Det kompilerar en enda .po till en enda .mo och är tillgängligt på praktiskt taget alla Linux- och macOS-system.

# 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

Flaggan -o namnger utdatafilen. Flaggan --statistics är verkligen användbar — den berättar hur många strängar som är översatta, osäkra eller fortfarande tomma, så att du kan upptäcka en ofullständig översättning innan du släpper den. För att skripta en fil i taget är msgfmt det pålitliga, enkla valet.

Eftersom msgfmt är ett rent kommandoradsverktyg passar det smidigt in i automatisering. Du kan linda in det i en shell-loop för att kompilera en hel mapp, eller koppla in det i en CI-pipeline så att varje commit som rör en .po automatiskt producerar en ny .mo. Ett vanligt mönster är for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, som kompilerar varje språk i en enda körning. Flaggan --check lägger till validering, och flaggar formatsträngsmissmatchningar mellan msgid och msgstr innan de når produktion — ett billigt skydd mot de trasiga platshållarbuggarna som tyst korrumperar översatta layouter.

Metod 3: Poedit (Kompilerar vid spara)

Om du redigerar översättningar i en grafisk redigerare kompilerar Poedit åt dig automatiskt. Varje gång du sparar en .po-fil skriver Poedit den matchande .mo direkt bredvid den — inget separat kommando, inget extra steg.

Detta är en anledning till att Poedit förblir populärt bland översättare som inte är bekväma med kommandoraden. Du öppnar .po, skriver dina översättningar, trycker på spara, och båda filerna uppdateras tillsammans. Du kan bekräfta beteendet under Poedit's inställningar, där automatisk .mo-kompilering vid spara är aktiverad som standard. Poedit och liknande skrivbordsverktyg recenseras i topp 5 gratis verktyg för att redigera och översätta PO-filer på Mac och Windows.

Nackdelen med en skrivbordsredigerare är att kompilering endast sker när en människa öppnar filen och sparar den. Det är bra för ett enmansprojekt, men det skalar inte till ett dussin språk eller ett team som skickar filer fram och tillbaka. Om någon redigerar en .po i ett annat verktyg och kopierar den till arkivet utan att öppna Poedit, uppdateras aldrig .mo. För större eller samarbetsprojekt eliminerar en automatiserad metod — kommandorad eller moln — det beroendet av att komma ihåg att trycka på spara.

Metod 4: Ett molnverktyg som genererar .mo åt dig

Det fjärde alternativet tar bort kompileringssteget helt: använd en molntjänst som returnerar den kompilerade .mo tillsammans med den översatta .po. Du kör aldrig ett kommando eller sparar en fil två gånger — du laddar upp, och färdiga, korrekt namngivna filer kommer tillbaka.

SimplePoTranslate fungerar exakt på detta sätt. Du laddar upp en .po eller .pot, den översätter strängarna med Context-Aware AI, och den returnerar en enda ZIP som innehåller .po och .mo genererade sida vid sida — redan kompilerade, redan namngivna för att matcha din textdomän och lokalisering. Det finns ingen separat kompileringskörning och ingen risk att glömma en.

Den hanterar också detaljerna som bryter manuella arbetsflöden. Syntaxlåsning fryser platshållare som %s, %1$s och {name} plus HTML-taggar före översättning, så dina variabler överlever in i .mo intakta. Fullt stöd för Gettext-plural innebär att komplexa pluralformer också kompileras korrekt — ett ämne värt att förstå på djupet, vilket vi täcker i förstå Gettext-pluraler. Och eftersom det körs i molnet finns det ingen plugin att installera och inga byggverktyg att underhålla.

Den vanligaste fallgropen: Du glömde att kompilera om

Den enskilt största anledningen till att översättningar inte visas är att du redigerar .po men glömmer att kompilera om .mo. WordPress fortsätter att ladda den gamla binärfilen, så din nya formulering visas aldrig — och det finns inget felmeddelande som berättar varför.

Den mentala modellen att låsa in: .po är ditt utkast, .mo är det som levereras. Alla ändringar i .po är osynliga för WordPress tills du återskapar .mo. Gör omkompilering till en reflex efter varje redigering, eller använd ett verktyg som kompilerar automatiskt så att steget aldrig kan hoppas över.

Denna fallgrop är särskilt förrädisk vid överlämningar från staging till produktion. En utvecklare redigerar och kompilerar om lokalt, ser översättningen fungera, distribuerar sedan bara .po och glömmer .mo — så produktionen behåller tyst den gamla texten. Närhelst du flyttar översättningsfiler mellan miljöer, flytta .po och den nykompilerade .mo tillsammans, eller kompilera som en del av ditt distributionssteg så att binärfilen alltid byggs om från den aktuella källan.

Om dina översättningar fortfarande vägrar att visas efter omkompilering, är problemet vanligtvis en namnmismatch, en felaktig mapp eller ett cachelager som håller den gamla filen. Den fullständiga checklistan finns i varför dina översättningar inte visas i WordPress.

En anteckning om det nyare .l10n.php-formatet

Nya WordPress-versioner introducerade ett tredje körningsformat: .l10n.php. Istället för en binär .mo, lagras översättningar som en enkel PHP-array som PHP:s opcode-cache kan hålla i minnet, vilket gör uppslagningar ännu snabbare än .mo på webbplatser med mycket trafik.

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

WordPress genererar .l10n.php-filer automatiskt när det har den matchande .mo tillgänglig, så du behöver inte bygga dem för hand. För närvarande förblir kompilering av en korrekt .mo grunden — prestandaformatet härleds från den.

Sammanfattning

För att kompilera po till mo pålitligt, välj den metod som passar ditt arbetssätt: WP-CLI för kommandoradsbatchar, msgfmt för enskilda filer med statistik, Poedit för automatisk kompilering vid spara, eller ett molnverktyg som bygger .mo åt dig så att steget aldrig hoppas över. Alla fyra producerar samma binärfil som WordPress behöver vid körning.

Vilken väg du än väljer, kom ihåg den gyllene regeln: redigera .po, kompilera sedan till .mo — varje gång. Den vanan förhindrar den mest frustrerande översättningsbuggen i WordPress, den där allt ser rätt ut men webbplatsen envist förblir på engelska.

Redo att hoppa över det manuella kompileringssteget för gott? Prova SimplePoTranslate gratis — inget kreditkort krävs. Ladda upp din .po och ladda ner ett färdigt att distribuera .po + .mo-paket på den kostnadsfria nivån på några minuter.