FunkciókBővítményÁrazásForrások
Nyelv módosítása
ForrásokHogyan hozzunk létre egy .pot fájlt egy téma vagy bővítmény számára

Hogyan hozzunk létre egy .pot fájlt egy téma vagy bővítmény számára

SimplePoTranslate Team2026. április 29.
Hogyan hozzunk létre egy .pot fájlt egy téma vagy bővítmény számára

Épp most fejezett be egy WordPress bővítményt, amit meg szeretne osztani a világgal. A kód működik, a funkciók stabilak, és valaki Németországból e-mailben megkérdezi, hogyan fordíthatná le németre. Rámutat a languages mappára, és rájön, hogy semmi sincs ott. Nincs sablon, nincsenek stringek, a fordító még azt sem tudja, mit kell fordítani. A bővítménye technikailag csak nevében „fordításra kész”.

Minden fordítható WordPress projekt egy fájllal kezdődik: a .pot sablonnal. Mielőtt bárki német, francia vagy japán verziót készítene, létre kell hoznia egy POT fájlt, amely felsorolja a kódjában lévő összes felhasználói felületen megjelenő stringet. Hagyja ki ezt a lépést, és a fordítók sorról sorra fogják olvasni a forráskódot, találgatva, mely stringeknek kellene láthatónak lenniük.

Ez az útmutató a munka két felén vezeti végig: a forráskód előkészítésén, hogy a stringek megtalálhatóak legyenek, majd magának a .pot fájlnak a generálásán három különböző eszközzel. Használni fogjuk a WP-CLI-t, a Poedit-et és a régebbi makepot/grunt megközelítést, valós, másolható parancsokkal. A végére egy tiszta sablonja lesz, amelyet bármely fordítónak átadhat.

Első lépés: Jelölje meg a stringjeit fordíthatóként

Mielőtt létrehozhatna egy POT fájlt, minden olyan stringet, amelyet egy felhasználó láthat, be kell csomagolni egy Gettext függvénybe. Egy szkenner csak azokat a stringeket tudja kinyerni, amelyeket felismer, és ezeket a függvényhívások alapján ismeri fel — az egyszerű string literálok láthatatlanok számára.

A WordPress a lokalizációs függvények egy családját biztosítja, mindegyik kissé eltérő kontextushoz:

// Return a translated string
$label = __( 'Add to Cart', 'my-plugin' );

// Echo a translated string directly
_e( 'Your cart is empty', 'my-plugin' );

// Translate with context to disambiguate identical words
$verb = _x( 'Post', 'verb: to publish', 'my-plugin' );

// Translate AND escape for safe HTML output
echo esc_html__( 'Welcome back', 'my-plugin' );

Minden hívás második argumentuma — 'my-plugin' — a text domain. Ez egyetlen névtér alá csoportosítja egy bővítmény vagy téma összes stringjét, így a WordPress tudja, melyik .mo fájlt töltse be számukra. A projektjében szereplő minden fordítható stringnek pontosan ugyanazt a text domaint kell használnia, különben néhány string soha nem fog lefordításra kerülni.

Használja az _x() függvényt, amikor egy szó kétértelmű. Az angol „Post” lehet főnév vagy ige, és sok nyelv különbözőképpen fordítja őket. A kontextus stringek segítik a fordítókat a megkülönböztetésben. És nyúljon az esc_html__() és esc_attr__() változatokhoz, amikor a lefordított string HTML-be kerül kiírásra, így egyszerre marad biztonságos és lokalizált.

Néhány szokás segíti a stringek kinyerhetőségét. Mindig egyszerű string literált adjon át első argumentumként — soha ne változót vagy összefűzést, mint például __( 'Hello ' . $name, 'my-plugin' ), mert a szkenner statikusan olvassa a forrásszöveget, és nem tudja feloldani a futásidejű értékeket. Számot tartalmazó mondatokhoz használja az _n() függvényt, hogy a többes számú alakok helyesen legyenek rögzítve, és dinamikus értékű mondatokhoz használja a sprintf() függvényt egy placeholder, például %s köré, ahelyett, hogy a stringeket összeragasztaná. Az itt lévő következetesség az, ami a következő lépést — a sablon generálását — teljessé és használhatóvá teszi.

Második lépés: Deklarálja a Text Domaint a fejlécben

A WordPressnek két fejlécmezőre van szüksége ahhoz, hogy tudja, hol találhatók a fordítások: a Text Domain-re és a Domain Path-re. Állítsa be őket a bővítmény fő fájljában vagy a téma style.css fájljában, és a WordPress futásidőben automatikusan betölti a megfelelő .mo fájlt.

<?php
/**
 * Plugin Name:       My Plugin
 * Description:        A perfectly localized WordPress plugin.
 * Version:            1.0.0
 * Requires at least: 6.4
 * Text Domain:       my-plugin
 * Domain Path:       /languages
 */

A Text Domain-nek meg kell egyeznie azzal a stringgel, amit minden __() és _e() hívásnak átadott — itt my-plugin. A Domain Path megmondja a WordPressnek, melyik almappa tartalmazza a fordítási fájlokat, a bővítmény vagy téma gyökérkönyvtárához képest. A konvenció /languages, és pontosan itt kell lennie a generált .pot fájljának.

Miután a stringek be vannak csomagolva, és a fejléc deklarálva van, a kódja készen áll a szkennelésre. A projekt fordításra való előkészítésének tágabb képe — beleértve azokat a témákat is, amelyek nem az Ön tulajdonában vannak — ebben a cikkben található: hogyan lokalizálhat bármilyen WordPress témát, még akkor is, ha nem fejlesztő.

Hogyan generálható a .pot fájl? Három módszer

A .pot fájlt úgy generálja, hogy futtat egy szkennert a forráskódján, amely megtalálja az összes Gettext hívást, és beírja a stringeket egy sablonba. Íme három megbízható módszer erre, a modern alapértelmezettől a régebbi megközelítésig.

1. módszer: WP-CLI (Ajánlott)

A POT fájl létrehozásának hivatalos, modern módja a WP-CLI az i18n paranccsal. A WordPress alapvető eszközkészletének része, érti a PHP és JavaScript stringeket, és egy sorban szabványos sablont készít.

# Run from your plugin or theme root directory
wp i18n make-pot . languages/my-plugin.pot

# Add a text domain explicitly if auto-detection misses it
wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin

# Scan only specific paths and exclude vendor folders
wp i18n make-pot . languages/my-plugin.pot --exclude=vendor,node_modules

Az első argumentum a forráskönyvtár (. az aktuális mappához), a második pedig a kimeneti útvonal. A WP-CLI végigmegy a fájljain, kinyeri az összes becsomagolt stringet, megjegyzi a forrásfájlt és a sor számát megjegyzésként, és megírja a .pot fájlt. Gyors, szkriptelhető, és a megfelelő választás bármilyen komoly projekthez.

A generált sablon hasznos metaadatokat tartalmaz, amelyeket extra jelzőkkel finomhangolhat. Adja át a --headers kapcsolót a projekt nevének, verziójának és a fordítók elérhetőségének beállításához, hogy a .pot fejlécblokkja helyesen legyen kitöltve, ne pedig placeholderként maradjon. A WP-CLI automatikusan kinyeri a JavaScript stringeket a wp_set_script_translations() hívásokból is, ami fontos a modern blokk-témák és Gutenberg bővítmények esetében, ahol a felhasználói felületen megjelenő szöveg fele JavaScriptben, nem pedig PHP-ben található. Egyetlen parancs lefedi mindkét világot.

2. módszer: Poedit (Grafikus)

Ha az asztali alkalmazásokat kedveli, a Poedit képes átvizsgálni a forráskódot és sablont generálni az interfészén keresztül. Nyissa meg a Poeditet, válassza az új fordítás létrehozását POT-ból vagy a források közvetlen szkennelését, mutasson rá a projektmappájára, és konfigurálja a forráskulcsszavakat (__, _e, _x, esc_html__) a katalógus tulajdonságai alatt.

A Poedit forráskód-szkennelő és .pot generáló funkciói a Pro kiadásában találhatók, de a munkafolyamat barátságos azoknak a fejlesztőknek, akik inkább kattintanak, mint parancsokat írnak be. Ez egy megbízható szerkesztő a következő fordítási fázishoz is. A Poeditet és számos más asztali lehetőséget összehasonlítunk a Top 5 ingyenes eszköz PO fájlok szerkesztéséhez és fordításához Mac és Windows rendszeren cikkben.

3. módszer: makepot / grunt (Örökség)

A WP-CLI előtt a standard eszköz a makepot.php szkript volt a WordPress i18n-tools repozitóriumából, gyakran Grunt build feladatba integrálva a grunt-wp-i18n segítségével. Régebbi bővítményekben és témákban még találkozhat vele.

# Legacy makepot.php invocation
php makepot.php wp-plugin /path/to/my-plugin languages/my-plugin.pot

Működik, de a WP-CLI-hez képest karbantartatlan és lassabb a beállítása. Csak akkor használja, ha egy olyan régebbi projektet tart karban, amely már függ tőle; minden új projekthez inkább a wp i18n make-pot parancsot részesítse előnyben.

Tartsa naprakészen a sablont, ahogy a kódja változik

A .pot a stringjeinek egy pillanatfelvétele. Minden alkalommal, amikor hozzáad egy funkciót, megváltoztat egy címkét, vagy kijavít egy elírást egy látható stringben, a sablon elavul, és a fordítók kihagyják az új megfogalmazást.

Tegye a regenerálást a kiadási rutinja részévé. Futtassa újra a wp i18n make-pot parancsot minden verziófrissítés előtt, majd egyesítse a frissített sablont a meglévő fordításokkal a wp i18n update-po vagy msgmerge segítségével, hogy a fordítók megőrizzék elkészült munkájukat, és csak az új hiányosságokat lássák. Tekintse a .pot fájlt egy generált build műterméknek, ne pedig egy kézzel szerkesztett fájlnak.

Az elavult sablon finom, frusztráló hibát okoz: új stringek jelennek meg angolul még egy „teljesen lefordított” oldalon is, mert soha nem szerepeltek a .pot fájlban, amellyel a fordító dolgozott. Ennek elkerülése olyan egyszerű, mint a regenerálás beillesztése a build folyamatába, így a sablon soha nem maradhat le a kódtól. Néhány csapat hozzáad egy CI ellenőrzést, amely meghiúsítja a buildet, ha a .pot újragenerálása eltérést mutat, ezzel garantálva, hogy a véglegesített sablon mindig megegyezzen az aktuális forráskóddal.

Miután a fordítók visszaküldik a kész .po fájlokat, azokat még le kell fordítani a bináris .mo fájllá, amelyet a WordPress ténylegesen betölt — és ha inkább kihagyná az egész letöltés-fordítás-újrakompilálás hurkot, egy felhőalapú eszköz képes kezelni ezt a folyamatot elejétől a végéig. A SimplePoTranslate közvetlenül fogadja az Ön .pot fájlját, lefordítja kontextusfüggő mesterséges intelligencia segítségével, amely megérti, mit jelent az egyes stringek az interfészében, és egyetlen ZIP fájlt ad vissza a már elkészült és elnevezett .po, .mo és más fájlokkal. A Syntax Locking funkciója rögzíti az olyan placeholder-eket, mint a %s és %1$s, így a változói soha nem törnek el a fordítás során.

Összefoglalás

A POT fájl megfelelő létrehozásához először tegye felfedezhetővé a kódját — csomagoljon be minden látható stringet a __(), _e(), _x() vagy egy escape változaton belül, mindezt egyetlen text domainnel, és deklarálja ezt a domaint, valamint a Domain Path értéket a fejlécében. Ezután generálja a sablont WP-CLI-vel új projektekhez, Poedittel, ha a GUI-t preferálja, vagy makepottal csak örökölt kód karbantartásakor.

Generáljon korán, regeneráljon gyakran, és soha ne hagyja, hogy a sablonja lemaradjon a kódja mögött. Az aktuális .pot jelenti a különbséget egy valóban világra kész bővítmény és egy csak annak mondott között.

Készen áll arra, hogy .pot sablonját kész fordításokká alakítsa a kézi fordítási tánc nélkül? Próbálja ki ingyen a SimplePoTranslate-et — nincs szükség hitelkártyára. Töltse fel sablonját az ingyenes szinten, és töltse le a szállításra kész fordítási fájlokat percek alatt.