.po vs .mo vs .pot: WordPress översättningsfiler förklaras

Du öppnar languages-mappen för ett WordPress-tema och hittar tre filer som ser nästan identiska ut: twentytwentyfour.pot, twentytwentyfour-de_DE.po och twentytwentyfour-de_DE.mo. Samma tema, samma språk, tre olika filändelser. Vilken redigerar du? Vilken laddar WordPress egentligen? Och varför gör redigering av fel fil att dina översättningar tyst försvinner?

Om du någonsin har undrat vilken fil som spelar roll i debatten om .po vs .mo-filer, är du inte ensam. Dessa tre filändelser är ryggraden i varje översatt WordPress-webbplats, men skillnaden mellan dem förbryllar både nybörjare och erfarna utvecklare. Redigera fel fil och dina tyska besökare ser fortfarande engelska. Redigera rätt fil men hoppa över ett steg och ingenting ändras heller.

Denna guide förklarar exakt vad .pot-, .po- och .mo-filer är, hur de förhåller sig till varandra inom GNU Gettext-arbetsflödet, var de finns i WordPress och varför du aldrig ska öppna en .mo-fil i en textredigerare. I slutet kommer du att veta vilken fil du ska röra och vilken du ska låta vara.

Vad är .pot-, .po- och .mo-filer?

Kort sagt: en .pot-fil är den tomma mallen, en .po-fil är din redigerbara översättning, och en .mo-fil är den kompilerade binärfilen som WordPress läser vid körning. De bildar en kedja, och varje länk har exakt en uppgift.

Dessa tre format kommer alla från GNU Gettext, lokaliseringssystemet som WordPress, Drupal och tusentals PHP- och C-projekt förlitar sig på. Gettext skiljer de källsträngar en utvecklare skriver från de översättningar en översättare tillhandahåller, så att samma kodbas kan tala dussintals språk utan att röra en enda rad PHP.

Tänk på det som ett receptkort. .pot-filen är det tomma kortet med plats för ingredienser men inga mängder. .po-filen är kortet ifyllt för en specifik maträtt. .mo-filen är den laminerade, maskinskanningsbara kopian som köket faktiskt använder under serveringen. Du skriver på papperskortet; du klottrar aldrig på det laminerade.

.pot-filen: Huvudmallen

En .pot-fil (Portable Object Template) innehåller varje översättningsbar sträng i ett tema eller tillägg, med översättningarna lämnade tomma. Det är huvudlistan som utvecklare skickar med så att översättare vet exakt vad som behöver översättas. Raderna för msgstr är tomma eftersom inget språk har valts ännu.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr ""

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr ""

Lägg märke till det tomma msgstr "". En .pot är en mall, inte en översättning. Du kopierar den en gång per språk och fyller i tomrummen. Du redigerar sällan en .pot för hand; den genereras om från källkoden när strängar ändras.

.po-filen: Din mänskligt redigerbara översättning

En .po-fil (Portable Object) är en kopia av .pot-filen med msgstr-raderna ifyllda för ett språk. Detta är filen som översättare och utvecklare faktiskt redigerar. Den är vanlig text, läsbar för människor och versionskontrollvänlig.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr "In den Warenkorb"

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr "Ihre Bestellung wurde an %s versandt"

msgid är den ursprungliga engelska källsträngen och får aldrig ändras. msgstr är din översättning. %s är en platshållare som måste förbli orörd i översättningen – att ta bort eller ändra ordningen på den är den vanligaste orsaken till brutna layouter, vilket vi behandlar utförligt i hur man översätter PO-filer utan att bryta kodvariabler.

.mo-filen: Den kompilerade binärfilen

En .mo-fil (Machine Object) är den kompilerade, binära versionen av din .po-fil. WordPress kan inte läsa .po-filer effektivt vid körning, så den laddar istället den förkompilerade .mo-filen. Att öppna en .mo-fil i en textredigerare visar oläsbara byte — den är avsedd för maskiner, inte människor.

När WordPress anropar load_textdomain() eller load_theme_textdomain(), letar den efter en .mo-fil, analyserar dess binära hashtabell och byter ut varje msgid mot den matchande msgstr direkt. Detta binära format gör uppslagningarna snabba även på webbplatser med tusentals strängar.

Hur förhåller sig de tre filerna i Gettext-arbetsflödet?

De bildar en enkelriktad pipeline: källkod blir en .pot-fil, .pot-filen blir en språkspecifik .po-fil, och varje .po-fil kompileras till en .mo-fil. Översättningar flödar alltid nedåt.

Här är hela livscykeln i ordning:

1. En utvecklare omsluter användarorienterade strängar i Gettext-funktioner som __() och _e() inuti PHP-källkoden.
2. Ett skanningsverktyg läser källkoden och genererar .pot-mallen som innehåller varje omsluten sträng.
3. En översättare kopierar .pot-filen till en språkspecifik .po-fil (till exempel de_DE.po) och fyller i varje msgstr.
4. Den färdiga .po-filen kompileras till en binär .mo-fil.
5. WordPress laddar .mo-filen vid körning och visar den översatta webbplatsen.

När utvecklaren lägger till nya strängar senare, genereras .pot-filen om, de nya posterna slås samman med varje befintlig .po-fil (med bevarande av gamla översättningar), översättaren fyller i luckorna och .po-filen kompileras om till .mo-filen. Cykeln upprepas under projektets livstid.

Den avgörande insikten: du redigerar .po-filen och kompilerar sedan till .mo. Du redigerar aldrig .mo-filen direkt, och du översätter aldrig inuti .pot-filen. Om du vill ha en djupare, heltäckande bild, går den ultimata guiden till WordPress-lokalisering igenom hela pipelinen med exempel.

Namngivningskonventioner och var filerna finns

WordPress är strikt när det gäller filnamn. Om du namnger fel kommer din perfekt översatta .mo-fil helt enkelt att ignoreras, eftersom WordPress söker efter en exakt matchning baserad på textdomänen och språkvarianten (locale).

Namnmönstret för tema- och tilläggsöversättningar är:

# Pattern: textdomain-locale.po / .mo
twentytwentyfour-de_DE.po      # German (Germany) translation
twentytwentyfour-de_DE.mo      # compiled binary WordPress loads
twentytwentyfour-fr_FR.po      # French (France)
twentytwentyfour.pot           # template, no locale suffix

textdomain matchar strängen som skickas som det andra argumentet till Gettext-funktioner som __( 'Add to Cart', 'twentytwentyfour' ). locale är en WordPress-språkkod som de_DE, fr_FR eller pt_BR. .pot-mallen har inget språktillägg eftersom den är språkneutral.

Placeringen är lika viktig som namngivningen. WordPress söker i några förutsägbara sökvägar:

• Temaöversättningar levereras i temats egen mapp wp-content/themes/your-theme/languages/.
• Tilläggsöversättningar levereras i wp-content/plugins/your-plugin/languages/.
• Översättningar från translate.wordpress.org och användaröversättningar hamnar i de globala katalogerna wp-content/languages/themes/ och wp-content/languages/plugins/, som har prioritet och överlever uppdateringar.

Lägg en korrekt namngiven de_DE.mo-fil i rätt mapp så ser tyska besökare tyska. Lägg den en mapp för djupt, eller stavfel i textdomänen, och WordPress faller tyst tillbaka till engelska utan felmeddelande. Om dina översättningar inte visas är en felaktig namngivning eller sökväg den vanliga boven, och felsökningsguiden för saknade översättningar täcker varje vanlig orsak.

Varför du aldrig ska redigera en .mo-fil direkt

Eftersom en .mo-fil är en kompilerad binärfil finns det inget säkert sätt att redigera den för hand – och varje ändring du tvingar in kommer att skrivas över nästa gång .po-filen kompileras om. .po-filen är källan till sanningen; .mo-filen är en förbrukningsbar byggartefakt.

Denna enda regel förklarar en stor del av supportärenden som "min översättning ändrades men webbplatsen uppdaterades inte". Någon justerar en sträng, sparar .po-filen och glömmer att kompilera om .mo-filen. WordPress fortsätter att ladda den gamla binärfilen, så den nya formuleringen visas aldrig. Lösningen är alltid: redigera .po, kompilera om till .mo, ladda om.

Det finns en andra anledning till att regeln är viktig: .mo-filer är inte diff-vänliga i versionskontroll. Eftersom de är binära, producerar en liten textändring en ogenomskinlig klump i din Git-historik som ingen granskare kan läsa. Att behålla .po-filen som den spårade källan till sanningen och behandla .mo-filen som en genererad artefakt håller ditt arkiv granskningsbart och dina översättningar spårbara.

Att göra detta manuellt över dussintals språk är tråkigt och felbenäget. Det är här ett molnbaserat arbetsflöde sparar rejält med tid. Verktyg som SimplePoTranslate översätter dina .po-strängar och ger tillbaka en enda ZIP-fil som innehåller de matchande .po- och .mo-filerna tillsammans – redan kompilerade, korrekt namngivna, redo att släppas in i wp-content/languages/. Det finns inget att kompilera manuellt och ingen risk för en föråldrad .mo-fil.

Det tillämpar också Syntaxlåsning, vilket fryser varje platshållare som %s, %1$s och {name}, plus HTML-taggar, före översättning. Dina variabler förblir intakta, så du skickar aldrig en .mo-fil som bryter en layout. Och eftersom det körs helt i molnet finns det inget extra tillägg som tynger ner din webbplats – du laddar upp en fil och laddar ner färdiga, kompilerade översättningar.

Sammanfattning

När distinktionen mellan .po- och .mo-filer väl klarnar, slutar hela WordPress översättningssystem att kännas mystiskt. .pot-filen är utvecklarens mall, .po-filen är översättarens redigerbara arbetskopia, och .mo-filen är den kompilerade binärfilen som WordPress faktiskt levererar till besökare. Översättningar flödar i en riktning – mall till .po till .mo – och du handredigerar endast den mellersta.

Kom ihåg de tre reglerna som förhindrar nittio procent av översättningsproblem: översätt aldrig inuti en .pot-fil, kompilera alltid om .mo-filen efter att du har redigerat en .po-fil, och matcha namngivningen textdomain-locale exakt. Följ dessa så kommer dina översatta strängar att visas varje gång.

Redo att sluta kämpa med att kompilera och namnge översättningsfiler för hand? Prova SimplePoTranslate gratis — inget kreditkort krävs. Ladda upp din .po- eller .pot-fil och få ett färdigt .po + .mo-paket tillbaka på den kostnadsfria nivån inom några minuter.