.po vs .mo vs .pot: Forklaring af WordPress oversættelsesfiler

Du åbner languages-mappen i et WordPress-tema og finder tre filer, der ser næsten identiske ud: twentytwentyfour.pot, twentytwentyfour-de_DE.po og twentytwentyfour-de_DE.mo. Samme tema, samme sprog, tre forskellige filtyper. Hvilken skal du redigere? Hvilken indlæser WordPress egentlig? Og hvorfor får redigering af den forkerte fil dine oversættelser til at forsvinde sporløst?

Hvis du nogensinde har spurgt, hvilken fil der betyder noget i po vs mo fil-debatten, er du ikke alene. Disse tre filtyper er rygraden i enhver oversat WordPress-side, men forskellen mellem dem forvirrer både begyndere og erfarne udviklere. Rediger den forkerte fil, og dine tyske besøgende ser stadig engelsk. Rediger den rigtige, men spring et trin over, og intet ændrer sig heller.

Denne guide forklarer præcis, hvad .pot-, .po- og .mo-filer er, hvordan de hænger sammen i GNU Gettext-arbejdsgangen, hvor de findes i WordPress, og hvorfor du aldrig bør åbne en .mo-fil i en teksteditor. Til sidst vil du vide, hvilken fil du skal røre ved, og hvilken du skal lade være.

Hvad er .pot-, .po- og .mo-filer?

Kort sagt: en .pot-fil er den tomme skabelon, en .po-fil er din redigerbare oversættelse, og en .mo-fil er den kompilerede binærfil, som WordPress læser under kørsel. De danner en kæde, og hvert led har præcis én opgave.

Disse tre formater stammer alle fra GNU Gettext, det lokaliseringssystem som WordPress, Drupal og tusindvis af PHP- og C-projekter bygger på. Gettext adskiller de kildestrenge, en udvikler skriver, fra de oversættelser, en oversætter leverer, så den samme kodebase kan tale snesevis af sprog uden at røre en eneste linje PHP-kode.

Tænk på det som et opskriftskort. .pot-filen er det blanke kort med felter til ingredienser, men uden mængder. .po-filen er kortet udfyldt for en bestemt ret. .mo-filen er den laminerede, maskinlæsbare kopi, som køkkenet faktisk bruger under servering. Du skriver på papirkortet; du kradser aldrig på det laminerede.

.pot-filen: Masterskabelonen

En .pot-fil (Portable Object Template) indeholder alle oversættelige strenge i et tema eller plugin, hvor oversættelserne er tomme. Det er den masterliste, udviklere sender med, så oversættere præcis ved, hvad der skal oversættes. msgstr-linjerne er tomme, fordi intet sprog endnu er valgt.

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

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

Bemærk den tomme msgstr "". En .pot er en skabelon, ikke en oversættelse. Du kopierer den én gang pr. sprog og udfylder felterne. Du redigerer sjældent en .pot manuelt; den genskabes fra kildekoden, hver gang strenge ændres.

.po-filen: Din menneske-redigerbare oversættelse

En .po-fil (Portable Object) er en kopi af .pot-filen, hvor msgstr-linjerne er udfyldt for ét sprog. Dette er den fil, oversættere og udviklere faktisk redigerer. Den er almindelig tekst, menneskelæselig og venlig over for versionsstyring.

#: 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 er den originale engelske kildestreng og må aldrig ændres. msgstr er din oversættelse. %s er en pladsholder, der skal overleve uberørt i oversættelsen – at fjerne eller omarrangere den er den hyppigste årsag til ødelagte layouts, hvilket vi dækker i dybden i hvordan man oversætter PO-filer uden at ødelægge kodevariabler.

.mo-filen: Den kompilerede binærfil

En .mo-fil (Machine Object) er den kompilerede, binære version af din .po-fil. WordPress kan ikke læse .po-filer effektivt under kørsel, så den indlæser i stedet den forhåndskompilerede .mo-fil. Åbning af en .mo-fil i en teksteditor viser ulæselige bytes — den er beregnet til maskiner, ikke mennesker.

Når WordPress kalder load_textdomain() eller load_theme_textdomain(), leder den efter en .mo-fil, parser dens binære hashtabel og udskifter hvert msgid med den matchende msgstr i farten. Dette binære format gør opslag hurtige, selv på sider med tusindvis af strenge.

Hvordan hænger de tre filer sammen i Gettext-arbejdsgangen?

De danner en ensrettet pipeline: kildekode bliver til en .pot, .pot-filen bliver til en sprogspecifik .po-fil, og hver .po-fil kompileres til en .mo-fil. Oversættelser flyder altid nedad.

Her er hele livscyklussen i rækkefølge:

1. En udvikler omslutter brugerrettede strenge i Gettext-funktioner som __() og _e() i PHP-kildekoden.
2. Et scanningsværktøj læser kildekoden og genererer .pot-skabelonen, der indeholder alle de omsluttede strenge.
3. En oversætter kopierer .pot-filen til en sprogspecifik .po-fil (f.eks. de_DE.po) og udfylder hver msgstr.
4. Den færdige .po-fil kompileres til en binær .mo-fil.
5. WordPress indlæser .mo-filen under kørsel og viser den oversatte side.

Når udvikleren senere tilføjer nye strenge, genskabes .pot-filen, de nye poster flettes ind i hver eksisterende .po-fil (hvor gamle oversættelser bevares), oversætteren udfylder hullerne, og .po-filen genkompileres til .mo. Cyklussen gentages i hele projektets levetid.

Den vigtigste pointe: du redigerer .po-filen, og kompilerer derefter til .mo. Du redigerer aldrig .mo-filen direkte, og du oversætter aldrig inde i .pot-filen. Hvis du ønsker det dybere end-to-end billede, gennemgår den ultimative guide til WordPress-lokalisering hele pipelinen med eksempler.

Nomenklatur og hvor filerne bor

WordPress er streng med filnavne. Hvis navngivningen er forkert, vil din perfekt oversatte .mo-fil simpelthen blive ignoreret, fordi WordPress søger efter et nøjagtigt match baseret på tekstdomænet og lokale.

Navngivningsmønsteret for tema- og plugin-oversættelser er:

# 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 matcher strengen, der sendes som det andet argument til Gettext-funktioner som __( 'Add to Cart', 'twentytwentyfour' ). locale er en WordPress-lokale-kode som de_DE, fr_FR eller pt_BR. .pot-skabelonen har ingen locale-suffiks, fordi den er sprogneutral.

Placering er lige så vigtig som navngivning. WordPress søger i et par forudsigelige stier:

• Temaoversættelser leveres i temaets egen mappe wp-content/themes/your-theme/languages/.
• Plugin-oversættelser leveres i wp-content/plugins/your-plugin/languages/.
• Oversættelser fra translate.wordpress.org og brugerdefinerede tilsidesættelser lander i de globale wp-content/languages/themes/ og wp-content/languages/plugins/ mapper, som har prioritet og overlever opdateringer.

Læg en korrekt navngivet de_DE.mo i den rigtige mappe, og tyske besøgende ser tysk. Læg den én mappe for dybt, eller stav tekstdomænet forkert, og WordPress falder stille tilbage til engelsk uden fejlmeddelelse. Hvis dine oversættelser ikke vises, er en fejl i navngivning eller sti den sædvanlige synder, og fejlfinding guiden for manglende oversættelser dækker alle almindelige årsager.

Hvorfor du aldrig bør redigere en .mo-fil direkte

Fordi en .mo-fil er en kompileret binærfil, er der ingen sikker måde at redigere den manuelt på — og enhver ændring, du gennemtvinger, vil blive overskrevet næste gang .po-filen genkompileres. .po-filen er sandhedens kilde; .mo-filen er et genanvendeligt byggeartefakt.

Denne ene regel forklarer en stor del af supporthenvendelser med titlen "min oversættelse er ændret, men siden er ikke opdateret". Nogen justerer en streng, gemmer .po-filen og glemmer at genkompilere .mo-filen. WordPress bliver ved med at indlæse den gamle binærfil, så den nye formulering vises aldrig. Løsningen er altid: rediger .po, genkompiler til .mo, genindlæs.

Der er en anden grund til, at reglen er vigtig: .mo-filer er ikke diff-venlige i versionsstyring. Fordi de er binære, producerer en lille ændring i ordlyden en uigennemsigtig 'blob' i din Git-historik, som ingen reviewer kan læse. Ved at beholde .po-filen som den spores sandhedskilde og behandle .mo-filen som et genereret artefakt forbliver dit repository gennemgåeligt og dine oversættelser auditerbare.

At gøre dette manuelt på tværs af snesevis af sprog er kedeligt og fejlbehæftet. Det er her en cloud-arbejdsgang sparer reel tid. Værktøjer som SimplePoTranslate oversætter dine .po-strenge og returnerer en enkelt ZIP-fil, der indeholder de matchende .po og .mo sammen — allerede kompileret, korrekt navngivet og klar til at blive droppet ind i wp-content/languages/. Der er intet at kompilere manuelt, og ingen chance for en forældet .mo-fil.

Det anvender også Syntax Locking, som fryser hver pladsholder som %s, %1$s og {name}, plus HTML-tags, før oversættelse. Dine variabler forbliver intakte, så du aldrig leverer en .mo-fil, der ødelægger et layout. Og fordi det kører helt i skyen, er der ingen ekstra plugin, der tynger din side — du uploader en fil og downloader færdige, kompilerede oversættelser.

Sammenfatning

Når forskellen mellem po vs mo fil giver mening, holder hele WordPress-oversættelsessystemet op med at føles mystisk. .pot-filen er udviklerens skabelon, .po-filen er oversætterens redigerbare arbejdskopi, og .mo-filen er den kompilerede binærfil, som WordPress faktisk serverer til besøgende. Oversættelser flyder i én retning — skabelon til .po til .mo — og du redigerer kun den midterste manuelt.

Husk de tre regler, der forhindrer halvfems procent af oversættelseshovedpiner: oversæt aldrig inde i en .pot-fil, genkompiler altid .mo-filen efter redigering af en .po-fil, og match textdomain-locale-navngivningen præcist. Følg dem, og dine oversatte strenge vil altid blive vist.

Klar til at stoppe med at kæmpe med manuel kompilering og navngivning af oversættelsesfiler? Prøv SimplePoTranslate gratis — intet kreditkort påkrævet. Upload din .po eller .pot, og få en klar-til-brug .po + .mo pakke tilbage på den gratis version inden for få minutter.