En fil in, fem format ut: Så här framtidssäkrar du dina WordPress-översättningar

Du spenderade tre veckor med att översätta ditt WordPress-tema till spanska. .po-filen är perfekt – varje sträng granskad, varje variabel intakt, varje pluralform korrekt. Sedan bestämmer sig din klient för att migrera från ett klassiskt PHP-tema till en headless-installation med React på frontend.

Plötsligt är din .po-fil värdelös. React-appen behöver .json. De äldre PHP-widgetarna behöver fortfarande .mo. Frilansaren som hanterar mobilappen vill ha .xliff. Och ingen har tid att översätta 4 000 strängar till tre olika format.

Detta är inte ett sällsynt fall. Det är verkligheten i modern WordPress-utveckling, där teman levereras med både PHP- och JavaScript-komponenter, plugins använder en blandning av Gettext och i18next, och klienter ändrar sig om arkitektur oftare än de ändrar sina lösenord.

Varför översättningsfilformat är viktigare än någonsin

För fem år sedan var WordPress-översättning enkelt. Du hade en .po-fil (läsbar källkod) och en .mo-fil (kompilerad binär). Det var allt. Varje tema, varje plugin, varje översättningsverktyg talade samma språk.

Idag använder WordPress-ekosystemet minst fem översättningsfilformat i produktion:

De fem formaten du behöver känna till

.po (Portable Object) – Det läsbara källformatet som används av GNU Gettext. Innehåller originalsträngar (msgid) och deras översättningar (msgstr). Det är detta översättare redigerar.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) – Den kompilerade binära versionen av en .po-fil. WordPress läser .mo-filer vid körning med hjälp av load_textdomain(). Snabbare än att parsa .po vid körning, men inte redigerbar av människor.

.json (JavaScript Object Notation) – Används av wp_set_script_translations() för JavaScript-baserade översättningar i Gutenberg-block, React-komponenter och moderna teman. WordPress förväntar sig en specifik JSON-struktur med locale_data-nycklar.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) – Ett alltmer populärt format för teman och plugins som använder översättningsladdning i Laravel-stil. Vissa moderna WordPress-teman kringgår Gettext helt och laddar översättningar från PHP-arrayer för prestanda.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) – Industristandarden för översättningsutbyte mellan olika verktyg och plattformar. Används av CAT-verktyg (Computer-Assisted Translation) som memoQ, Trados och Memsource. Viktigt när du arbetar med professionella mänskliga översättare.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Problemet: Formatlåsning

De flesta översättningsverktyg producerar ett utdataformat. Poedit ger dig .po och .mo. WPML lagrar översättningar i databasen (inte i filer alls). Weglot behåller översättningar på sina servrar i ett proprietärt format. Även TMS-plattformar som Crowdin och Lokalise kräver att du manuellt konfigurerar exportformat för varje projekt.

Detta skapar formatlåsning – dina översättningar är fast i det format som ditt nuvarande verktyg producerar. När dina krav ändras står du inför två alternativ:

1. Översätt om allt i det nya formatet (dyrt, tidskrävande och du förlorar alla manuella korrigeringar)
2. Skriv anpassade konverteringsskript (felbenäget, särskilt för komplexa pluralformer och variabler) Inget av alternativen är bra. Båda slösar tid och pengar. Båda introducerar risker.

Verkliga scenarier där formatlåsning skadar

Scenario 1: Temamodernisering. Din klients tema byggs om med Gutenberg-block. De gamla PHP-mallarna använde .mo-filer. De nya blocken behöver .json för wp_set_script_translations(). Dina 3 000 översatta strängar måste finnas i båda formaten under övergången.

Scenario 2: Byråns arbetsflöde. Du hanterar 20 klientwebbplatser. Vissa använder klassiska teman (.mo). Vissa använder headless-installationer (.json). En använder ett anpassat ramverk som läser PHP-arrayer. Du behöver samma översättningar i olika format för olika klienter.

Scenario 3: Professionell granskning. Dina AI-översättningar är 95 % korrekta, men du vill att en person med språket som modersmål ska granska de återstående 5 %. Professionella översättare använder CAT-verktyg som importerar .xliff. Du måste exportera dina översättningar till .xliff, skicka dem för granskning och slå samman korrigeringarna tillbaka.

Scenario 4: Plattformsmigrering. Din klient flyttar från WordPress till en anpassad Node.js-applikation. Den nya appen använder i18next och behöver .json-filer. Dina 5 000 översatta strängar i .po-format måste konverteras – utan att förlora en enda variabel eller pluralform.

Lösningen: Översätt en gång, få alla format

SimplePoTranslate har ett annat tillvägagångssätt. När du laddar upp en .po-, .pot-, .json- eller .xliff-fil och kör en översättning, får du tillbaka en ZIP som innehåller alla fem format:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Detta är inte en "premiumfunktion" låst bakom en företagsnivå. Varje betald plan – Pro (19 USD/månad) och Lifetime (399 USD engångsavgift) – inkluderar alla fem utdataformat i varje översättningsjobb.

Varför detta är viktigt för framtidssäkring

När du har alla fem format från början behöver du aldrig översätta om. Dina översättningar är en tillgång som anpassar sig till alla tekniska krav:

• Klienten migrerar från klassiskt till Gutenberg? Distribuera .json-filen.
• Ny utvecklare föredrar PHP-arrayer? Ge dem .php-filen.
• Professionell översättare vill granska? Skicka .xliff-filen.
• Flyttar du till ett annat CMS? .json- och .xliff-filerna är plattformsoberoende.

Du översätter en gång. Formatet är redo när du behöver det.

Hur varje format fungerar i WordPress

Att veta vilken fil som ska vart är viktigt för en ren distribution.

Distribuera .mo-filer (klassiska PHP-teman och plugins)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress laddar dessa automatiskt när webbplatsens språk matchar. Inget plugin krävs. Noll databasoverhead. Detta är tillvägagångssättet som ger den bästa prestandan.

Distribuera .json-filer (Gutenberg-block och JS-komponenter)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Filnamnet innehåller skripthandtaget och en MD5-hash. WordPress matchar dessa när du anropar wp_set_script_translations() i ditt plugin eller tema. Om du bygger Gutenberg-block är det här filen som gör att dina översatta blocketiketter och beskrivningar visas korrekt.

Använda .xliff-filer (professionellt granskningsarbetsflöde)

.xliff-filer distribueras inte till WordPress. De används som ett utbytesformat när du behöver skicka översättningar till en professionell granskare eller importera dem till ett CAT-verktyg. Arbetsflödet ser ut så här:

1. Ladda upp .po till SimplePoTranslate och få .xliff i ZIP
2. Skicka .xliff till din översättare eller granskare
3. Ta emot korrigerad .xliff tillbaka
4. Ladda upp korrigerad .xliff till SimplePoTranslate och få uppdaterad .mo och .json

Detta tur-och-retur-arbetsflöde bevarar varje variabel och pluralform eftersom SimplePoTranslate's Syntax Locking skyddar dem i varje steg.

Leverantörslåsningstestet

Här är ett enkelt test för att avgöra om ditt nuvarande översättningsarbetsflöde har ett inlåsningsproblem:

1. Kan du exportera dina översättningar som standard .po-filer just nu?
2. Om du avbryter din prenumeration på översättningsverktyget idag, behåller du varje översatt sträng?
3. Kan du importera dina översättningar till ett helt annat verktyg eller plattform utan att översätta om?

Om svaret på något av dessa är "nej" är du inlåst. Tjänster som Weglot och GTranslate misslyckas med alla tre frågor – avbryt prenumerationen och dina översättningar försvinner. WPML lagrar översättningar i databasen, vilket gör export möjlig men smärtsam. Även skrivbordsverktyg som Poedit klarar testet på papperet men begränsar dig till endast .po och .mo.

Med SimplePoTranslate är svaret på alla tre frågor "ja". Du laddar ner standardfiler i fem format. De är dina. Radera ditt konto imorgon och varje översättning du någonsin gjort fungerar fortfarande.

Bygga ett formatagnostiskt översättningsbibliotek

För byråer och utvecklare som hanterar flera projekt är det smartaste tillvägagångssättet att bygga ett översättningsbibliotek – ett Git-arkiv eller delad mapp där du lagrar översatta filer för varje klientprojekt.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

När en klient behöver ett nytt format har du det redan. När en klient byter plattformar migreras dina översättningar utan ansträngning. När en ny utvecklare går med i teamet kan de se exakt vad som har översatts och i vilka format.

Det är detta "framtidssäkert" faktiskt betyder – inte att förutsäga vilken teknik dina klienter kommer att använda nästa år, utan att se till att dina översättningar fungerar med vad de än väljer.

Redo att sluta oroa dig för filformat? Prova SimplePoTranslate gratis – ladda upp en fil, få tillbaka fem format. Inga konverteringsskript, ingen ny översättning, ingen inlåsning.