Én fil ind, fem formater ud: Sådan fremtidssikrer du dine WordPress-oversættelser

Du har brugt tre uger på at oversætte dit WordPress-tema til spansk. .po-filen er perfekt – hver streng er gennemgået, hver variabel er intakt, hver flertalsform er korrekt. Så beslutter din klient sig for at migrere fra et klassisk PHP-tema til en headless opsætning med React på frontend.

Pludselig er din .po-fil ubrugelig. React-appen skal bruge .json. De ældre PHP-widgets skal stadig bruge .mo. Freelanceren, der håndterer mobilappen, vil have .xliff. Og ingen har tid til at genoversætte 4.000 strenge til tre forskellige formater.

Dette er ikke et sjældent tilfælde. Det er virkeligheden i moderne WordPress-udvikling, hvor temaer leveres med både PHP- og JavaScript-komponenter, plugins bruger en blanding af Gettext og i18next, og klienter skifter mening om arkitektur oftere end de skifter adgangskoder.

Hvorfor oversættelsesfilformater betyder mere end nogensinde

For fem år siden var WordPress-oversættelse simpelt. Du havde en .po-fil (menneskeligt læsbar kilde) og en .mo-fil (kompileret binær). Det var det. Hvert tema, hvert plugin, hvert oversættelsesværktøj talte det samme sprog.

I dag bruger WordPress-økosystemet mindst fem oversættelsesfilformater i produktion:

De fem formater, du skal kende

.po (Portable Object) — Det menneskeligt læsbare kildeformat, der bruges af GNU Gettext. Indeholder originale strenge (msgid) og deres oversættelser (msgstr). Det er det, oversættere redigerer.

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 kompilerede binære version af en .po-fil. WordPress læser .mo-filer ved kørsel ved hjælp af load_textdomain(). Hurtigere end at parse .po ved kørsel, men ikke menneskeligt redigerbar.

.json (JavaScript Object Notation) — Bruges af wp_set_script_translations() til JavaScript-baserede oversættelser i Gutenberg-blokke, React-komponenter og moderne temaer. WordPress forventer en specifik JSON-struktur med locale_data-nøgler.

{
  "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) — Et stadig mere populært format til temaer og plugins, der bruger Laravel-lignende oversættelsesindlæsning. Nogle moderne WordPress-temaer omgår Gettext fuldstændigt og indlæser oversættelser fra PHP-arrays for at opnå bedre ydeevne.

<?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 for oversættelsesudveksling mellem forskellige værktøjer og platforme. Bruges af CAT-værktøjer (Computer-Assisted Translation) som memoQ, Trados og Memsource. Vigtigt, når du arbejder med professionelle menneskelige oversættere.

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

Problemet: Format Lock-In

De fleste oversættelsesværktøjer producerer ét outputformat. Poedit giver dig .po og .mo. WPML gemmer oversættelser i databasen (slet ikke i filer). Weglot opbevarer oversættelser på deres servere i et proprietært format. Selv TMS-platforme som Crowdin og Lokalise kræver, at du manuelt konfigurerer eksportformater for hvert projekt.

Dette skaber format lock-in – dine oversættelser er fanget i det format, dit nuværende værktøj producerer. Når dine krav ændrer sig, står du over for to muligheder:

1. Genoversæt alt i det nye format (dyrt, tidskrævende, og du mister eventuelle manuelle rettelser)
2. Skriv brugerdefinerede konverteringsscripts (fejlbehæftet, især for komplekse flertalsformer og variabler)

Ingen af mulighederne er gode. Begge spilder tid og penge. Begge introducerer risiko.

Virkelige scenarier, hvor format lock-in gør ondt

Scenarie 1: Temamodernisering. Din klients tema bliver genopbygget med Gutenberg-blokke. De gamle PHP-skabeloner brugte .mo-filer. De nye blokke skal bruge .json til wp_set_script_translations(). Dine 3.000 oversatte strenge skal eksistere i begge formater under overgangen.

Scenarie 2: Bureau workflow. Du administrerer 20 klientsider. Nogle bruger klassiske temaer (.mo). Nogle bruger headless opsætninger (.json). En bruger et brugerdefineret framework, der læser PHP-arrays. Du har brug for de samme oversættelser i forskellige formater til forskellige klienter.

Scenarie 3: Professionel gennemgang. Dine AI-oversættelser er 95 % nøjagtige, men du vil have en person med sproget som modersmål til at gennemgå de resterende 5 %. Professionelle oversættere bruger CAT-værktøjer, der importerer .xliff. Du skal eksportere dine oversættelser til .xliff, sende dem til gennemsyn og flette rettelserne tilbage.

Scenarie 4: Platformmigration. Din klient flytter fra WordPress til en brugerdefineret Node.js-applikation. Den nye app bruger i18next og skal bruge .json-filer. Dine 5.000 oversatte strenge i .po-format skal konverteres – uden at miste en eneste variabel eller flertalsform.

Løsningen: Oversæt én gang, få alle formater

SimplePoTranslate har en anden tilgang. Når du uploader en .po, .pot, .json eller .xliff-fil og kører en oversættelse, får du en ZIP-fil tilbage, der indeholder alle fem formater:

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

Dette er ikke en "premium-funktion", der er låst bag et enterprise-niveau. Hver betalt plan – Pro ($19/måned) og Lifetime ($399 engangsbeløb) – inkluderer alle fem outputformater i hvert oversættelsesjob.

Hvorfor dette er vigtigt for fremtidssikring

Når du har alle fem formater fra starten, behøver du aldrig at genoversætte. Dine oversættelser er et aktiv, der tilpasser sig ethvert teknisk krav:

• Klienten migrerer fra klassisk til Gutenberg? Implementer .json-filen.
• Ny udvikler foretrækker PHP-arrays? Giv dem .php-filen.
• Professionel oversætter vil gennemgå? Send .xliff-filen.
• Flytter til et andet CMS? .json- og .xliff-filerne er platformsuafhængige.

Du oversætter én gang. Formaterne er klar, når du har brug for dem.

Sådan fungerer hvert format i WordPress

At vide, hvilken fil der skal hvorhen, er afgørende for en ren implementering.

Implementering af .mo-filer (klassiske PHP-temaer og plugins)

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

WordPress indlæser disse automatisk, når sidens sprog stemmer overens. Intet plugin kræves. Ingen database overhead. Dette er den tilgang, der leverer den bedste ydeevne.

Implementering af .json-filer (Gutenberg-blokke og JS-komponenter)

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

Filnavnet inkluderer scripthåndtaget og et MD5-hash. WordPress matcher disse, når du kalder wp_set_script_translations() i dit plugin eller tema. Hvis du bygger Gutenberg-blokke, er det denne fil, der får dine oversatte bloketiketter og beskrivelser til at vises korrekt.

Brug af .xliff-filer (professionel gennemgangs workflow)

.xliff-filer implementeres ikke i WordPress. De bruges som et udvekslingsformat, når du skal sende oversættelser til en professionel korrekturlæser eller importere dem til et CAT-værktøj. Arbejdsgangen ser sådan ud:

1. Upload .po til SimplePoTranslate og få .xliff i ZIP-filen
2. Send .xliff til din oversætter eller korrekturlæser
3. Modtag rettet .xliff tilbage
4. Upload rettet .xliff til SimplePoTranslate og få opdateret .mo og .json

Denne tur-retur-arbejdsgang bevarer hver variabel og flertalsform, fordi SimplePoTranslates Syntax Locking beskytter dem på hvert trin.

Vendor Lock-In testen

Hern er en simpel test til at afgøre, om din nuværende oversættelsesworkflow har et lock-in-problem:

1. Kan du eksportere dine oversættelser som standard .po-filer lige nu?
2. Hvis du opsiger dit abonnement på oversættelsesværktøjet i dag, beholder du så hver oversat streng?
3. Kan du importere dine oversættelser til et helt andet værktøj eller platform uden at genoversætte?

Hvis svaret på et af disse er "nej", er du låst inde. Tjenester som Weglot og GTranslate dumper på alle tre spørgsmål – opsig abonnementet, og dine oversættelser forsvinder. WPML gemmer oversættelser i databasen, hvilket gør eksport mulig, men smertefuld. Selv desktopværktøjer som Poedit består testen på papiret, men begrænser dig kun til .po og .mo.

Med SimplePoTranslate er svaret på alle tre spørgsmål "ja". Du downloader standardfiler i fem formater. De er dine. Slet din konto i morgen, og hver oversættelse, du nogensinde har lavet, vil stadig fungere.

Opbygning af et format-agnostisk oversættelsesbibliotek

For bureauer og udviklere, der administrerer flere projekter, er den smarteste tilgang at opbygge et oversættelsesbibliotek – et Git-repository eller en delt mappe, hvor du gemmer oversatte filer til hvert 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 har brug for et nyt format, har du det allerede. Når en klient skifter platform, migrerer dine oversættelser uden besvær. Når en ny udvikler slutter sig til teamet, kan de se præcis, hvad der er blevet oversat, og i hvilke formater.

Dette er, hvad "fremtidssikret" faktisk betyder – ikke at forudsige, hvilken teknologi dine klienter vil bruge næste år, men at sikre, at dine oversættelser fungerer med det, de vælger.

Klar til at stoppe med at bekymre dig om filformater? Prøv SimplePoTranslate gratis – upload én fil, få fem formater tilbage. Ingen konverteringsscripts, ingen genoversættelse, ingen lock-in.