FunkciókBővítményÁrazásForrások
Nyelv módosítása
ForrásokEgy fájl be, öt formátum ki: Hogyan teheted jövőbiztossá WordPress fordításaidat

Egy fájl be, öt formátum ki: Hogyan teheted jövőbiztossá WordPress fordításaidat

SimplePoTranslate Team2026. március 21.
Egy fájl be, öt formátum ki: Hogyan teheted jövőbiztossá WordPress fordításaidat

Három hetet töltöttél azzal, hogy lefordítsd a WordPress témádat spanyolra. A .po fájl tökéletes — minden szöveg átnézve, minden változó érintetlen, minden többes szám helyes. Aztán az ügyfeled úgy dönt, hogy migrálnak egy klasszikus PHP témáról egy headless beállításra Reacttel a frontend oldalon.

És hirtelen a .po fájlod használhatatlan. A React alkalmazásnak .json kell. A régi PHP widgeteknek még .mo kell. A mobilalkalmazást kezelő freelancer .xliff-et akar. És senkinek nincs ideje arra, hogy 4000 szöveget három különböző formátumba újra lefordítson.

Ez nem egyedi eset. Ez a modern WordPress fejlesztés valósága, ahol a témák PHP és JavaScript komponensekkel is rendelkeznek, a bővítmények a Gettext és az i18next keverékét használják, és az ügyfelek gyakrabban változtatják meg az architektúrájukat, mint a jelszavukat.

Miért fontosabbak a fordítási fájlformátumok, mint valaha

Öt évvel ezelőtt a WordPress fordítás egyszerű volt. Volt egy .po fájlod (ember által olvasható forrás) és egy .mo fájlod (lefordított bináris). Ennyi. Minden téma, minden bővítmény, minden fordítóeszköz ugyanazon a nyelven beszélt.

Ma a WordPress ökoszisztéma legalább öt fordítási fájlformátumot használ éles környezetben:

Az öt formátum, amit ismerned kell

.po (Portable Object) — A GNU Gettext által használt ember által olvasható forrásformátum. Tartalmazza az eredeti szövegeket (msgid) és azok fordításait (msgstr). Ezt szerkesztik a fordítók.

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) — A .po fájl lefordított bináris verziója. A WordPress a .mo fájlokat futásidőben olvassa be a load_textdomain() segítségével. Gyorsabb, mint a .po futásidejű elemzése, de nem szerkeszthető ember által.

.json (JavaScript Object Notation) — A wp_set_script_translations() használja a JavaScript-alapú fordításokhoz a Gutenberg blokkokban, React komponensekben és modern témákban. A WordPress egy adott JSON struktúrát vár el locale_data kulcsokkal.

{
  "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 tömb) — Egyre népszerűbb formátum a Laravel-stílusú fordításbetöltést használó témák és bővítmények számára. Néhány modern WordPress téma teljesen kihagyja a Gettextet, és PHP tömbökből tölti be a fordításokat a teljesítmény érdekében.

<?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) — Az iparági szabvány a különböző eszközök és platformok közötti fordítási cseréhez. CAT (Computer-Assisted Translation) eszközök használják, mint például a memoQ, Trados és Memsource. Elengedhetetlen, ha professzionális emberi fordítókkal dolgozol.

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

A probléma: Formátumfüggőség

A legtöbb fordítóeszköz egyetlen kimeneti formátumot állít elő. A Poedit .po és .mo fájlokat ad. A WPML az adatbázisban tárolja a fordításokat (egyáltalán nem fájlokban). A Weglot a szerverein tárolja a fordításokat egy saját formátumban. Még a TMS platformok, mint a Crowdin és a Lokalise is megkövetelik, hogy manuálisan konfiguráld az export formátumokat minden projekthez.

Ez formátumfüggőséget teremt — a fordításaid abban a formátumban vannak csapdába esve, amelyet a jelenlegi eszközöd előállít. Amikor a követelményeid megváltoznak, két lehetőséggel szembesülsz:

  1. Mindent újra lefordítani az új formátumban (drága, időigényes, és elveszíted az esetleges manuális javításokat)
  2. Egyéni konvertáló szkripteket írni (hibalehetőségekkel teli, különösen összetett többes számok és változók esetén)

Egyik lehetőség sem jó. Mindkettő időt és pénzt pazarol. Mindkettő kockázatot jelent.

Valós helyzetek, ahol a formátumfüggőség fáj

1. forgatókönyv: Témat modernizálása. Ügyfeled témáját Gutenberg blokkokkal építik át. A régi PHP sablonok .mo fájlokat használtak. Az új blokkoknak .json kell a wp_set_script_translations() számára. A 3000 lefordított szövegednek mindkét formátumban léteznie kell az átmenet során.

2. forgatókönyv: Ügynökségi munkafolyamat. 20 ügyféloldalt kezelsz. Néhányan klasszikus témákat használnak (.mo). Néhányan headless beállításokat (.json). Egyikük egy egyéni keretrendszert használ, amely PHP tömböket olvas. Ugyanazokra a fordításokra van szükséged különböző formátumokban különböző ügyfelek számára.

3. forgatókönyv: Szakmai felülvizsgálat. A mesterséges intelligencia fordításaid 95%-ban pontosak, de azt szeretnéd, hogy egy anyanyelvi beszélő átnézze a fennmaradó 5%-ot. A professzionális fordítók CAT eszközöket használnak, amelyek importálják az .xliff fájlokat. Ki kell exportálnod a fordításaidat .xliff-be, el kell küldened őket felülvizsgálatra, és vissza kell egyesítened a javításokat.

4. forgatókönyv: Platformmigráció. Ügyfeled a WordPressről egy egyéni Node.js alkalmazásra költözik. Az új alkalmazás i18nextet használ, és .json fájlokra van szüksége. Az 5000 lefordított szövegedet .po formátumban konvertálni kell — anélkül, hogy egyetlen változót vagy többes számot is elveszítenél.

A megoldás: Fordíts le egyszer, szerezz meg minden formátumot

A SimplePoTranslate más megközelítést alkalmaz. Amikor feltöltesz egy .po, .pot, .json vagy .xliff fájlt, és futtatsz egy fordítást, kapsz vissza egy ZIP-et, amely mind az öt formátumot tartalmazza:

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

Ez nem egy "prémium funkció", amelyet egy vállalati szint mögé zártak. Minden fizetős csomag — Pro (19 USD/hónap) és Lifetime (399 USD egyszeri díj) — tartalmazza mind az öt kimeneti formátumot minden fordítási feladatban.

Miért fontos ez a jövőbiztosság szempontjából?

Ha kezdetektől fogva mind az öt formátummal rendelkezel, soha nem kell újra lefordítanod. A fordításaid egy érték, amely alkalmazkodik bármilyen technikai követelményhez:

  • Az ügyfél klasszikusról Gutenbergre migrált? Telepítsd a .json fájlt.
  • Az új fejlesztő a PHP tömböket preferálja? Add oda neki a .php fájlt.
  • A professzionális fordító felül akarja vizsgálni? Küldd el az .xliff fájlt.
  • Más CMS-re költözöl? A .json és .xliff fájlok platformfüggetlenek.

Egyszer fordítasz. A formátumok készen állnak, amikor szükséged van rájuk.

Hogyan működik az egyes formátumok a WordPressben

Fontos tudni, hogy melyik fájl hova kerül, a tiszta telepítéshez.

.mo fájlok telepítése (Klasszikus PHP témák és bővítmények)

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

A WordPress ezeket automatikusan betölti, ha az oldal nyelve megegyezik. Nincs szükség bővítményre. Nulla adatbázis terhelés. Ez az a megközelítés, amely a legjobb teljesítményt nyújtja.

.json fájlok telepítése (Gutenberg blokkok és JS komponensek)

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

A fájlnév tartalmazza a szkript fogantyúját és egy MD5 hash-t. A WordPress ezeket illeszti, amikor meghívod a wp_set_script_translations() függvényt a bővítményedben vagy a témádban. Ha Gutenberg blokkokat építesz, ez az a fájl, amely biztosítja, hogy a lefordított blokk címkék és leírások helyesen jelenjenek meg.

.xliff fájlok használata (Professzionális felülvizsgálati munkafolyamat)

Az .xliff fájlokat nem telepítik a WordPressre. Ezeket csereformátumként használják, amikor fordításokat kell küldened egy professzionális felülvizsgálónak, vagy be kell importálnod őket egy CAT eszközbe. A munkafolyamat így néz ki:

  1. Töltsd fel a .po-t a SimplePoTranslate-be, és szerezz be .xliff-et a ZIP-ben
  2. Küldd el az .xliff-et a fordítódnak vagy felülvizsgálódnak
  3. Vedd vissza a javított .xliff-et
  4. Töltsd fel a javított .xliff-et a SimplePoTranslate-be, és szerezz frissített .mo-t és .json-t

Ez a körkörös munkafolyamat megőrzi az összes változót és többes számot, mert a SimplePoTranslate Szintaxis Zárolása minden szakaszban védi őket.

A szállítói kötöttség tesztje

Itt van egy egyszerű teszt annak megállapítására, hogy a jelenlegi fordítási munkafolyamatodnak van-e kötöttségi problémája:

  1. Ki tudod exportálni a fordításaidat szabványos .po fájlokként most azonnal?
  2. Ha ma lemondod a fordítóeszköz előfizetésedet, megtartasz minden lefordított szöveget?
  3. Be tudod importálni a fordításaidat egy teljesen más eszközbe vagy platformra újrafordítás nélkül?

Ha bármelyikre a válasz "nem", akkor kötött vagy. Az olyan szolgáltatások, mint a Weglot és a GTranslate mindhárom kérdésben megbuknak — mondd le az előfizetést, és a fordításaid eltűnnek. A WPML az adatbázisban tárolja a fordításokat, ami lehetővé teszi az exportot, de fájdalmassá teszi. Még az olyan asztali eszközök is, mint a Poedit, papíron átmennek a teszten, de csak a .po-ra és .mo-ra korlátoznak.

A SimplePoTranslate segítségével mindhárom kérdésre a válasz "igen". Szabványos fájlokat töltesz le öt formátumban. A tiéd. Holnap töröld a fiókodat, és minden fordítás, amit valaha is készítettél, továbbra is működni fog.

Formátumfüggetlen fordítási könyvtár építése

A több projektet kezelő ügynökségek és fejlesztők számára a legokosabb megközelítés egy fordítási könyvtár létrehozása — egy Git tároló vagy egy megosztott mappa, ahol minden ügyfélprojekthez tárolod a lefordított fájlokat.

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/
│   └── ...

Ha egy ügyfélnek új formátumra van szüksége, már megvan az. Ha egy ügyfél platformot vált, a fordításaid nulla erőfeszítéssel migrálódnak. Amikor egy új fejlesztő csatlakozik a csapathoz, pontosan láthatja, hogy mi lett lefordítva és milyen formátumokban.

Ez az, amit a "jövőbiztos" valójában jelent — nem megjósolni, hogy ügyfeleid milyen technológiát fognak használni jövőre, hanem biztosítani, hogy a fordításaid bármivel működjenek, amit választanak.

Készen állsz arra, hogy ne aggódj a fájlformátumok miatt? Próbáld ki ingyen a SimplePoTranslate-et — tölts fel egy fájlt, és kapsz vissza öt formátumot. Nincsenek konvertáló szkriptek, nincs újrafordítás, nincs kötöttség.