Hur man översätter ett WordPress-plugin (Steg för steg)

Du hittade det perfekta WordPress-pluginet för ditt projekt. Det gör precis vad du behöver, recensionerna är strålande, och sedan aktiverar du det och inser att varje knapp, etikett och felmeddelande är på engelska. Dina tyska, franska eller japanska besökare är på väg att stöta på en textvägg de inte kan läsa.

Den goda nyheten är att de flesta välgjorda plugin är översättningsklara, vilket betyder att utvecklaren har omslutit sina strängar i Gettext-funktioner just för att folk som du ska kunna översätta dem. Utmaningen är att veta var filerna finns, vad din översättning ska heta och var du ska placera den så att nästa plugin-uppdatering inte raderar ditt arbete.

Den här guiden visar dig hur du översätter ett WordPress-plugin från början till slut: hur du hittar textdomänen och språkmappen, hämtar eller genererar .pot-mallen, bygger korrekt namngivna .po- och .mo-filer och placerar dem där WordPress tillförlitligt kommer att ladda dem. Vi kommer också att täcka den enda typen av plugin som denna metod inte fullt ut kan översätta, så att du inte slösar timmar på att kämpa mot ett omöjligt fall.

Hur hittar du ett plugins översättningsfiler?

Innan du översätter något behöver du två uppgifter från pluginet: dess textdomän och dess språkmapp. Textdomänen är den unika sträng som pluginet använder för att identifiera sina egna översättningar, och språkmappen är där källmallen finns.

Lokalisera språkmappen och textdomänen

Öppna plugin-katalogen på wp-content/plugins/your-plugin/ och leta efter en undermapp som heter /languages. Där inne hittar du vanligtvis en .pot-fil, den tomma mallen som innehåller alla översättningsbara strängar.

För att bekräfta textdomänen, öppna pluginets huvudsakliga .php-fil och titta på dess rubrikblock:

/**
 * Plugin Name: Awesome Plugin
 * Text Domain: awesome-plugin
 * Domain Path: /languages
 */

Här är textdomänen awesome-plugin. Detta värde är avgörande, eftersom dina översättningsfiler måste inkludera det i sina namn, annars kommer WordPress aldrig att matcha dem med pluginet. Du kommer också att se det i varje stränganrop i hela koden:

echo __( 'Settings saved successfully.', 'awesome-plugin' );

Det andra argumentet, awesome-plugin, är textdomänen igen. Varje sträng som använder den kan översättas av din katalog. Om en sträng i pluginets gränssnitt saknar denna omslutning, till exempel en utvecklare som hårdkodade echo 'Save' utan __(), då är den strängen inte översättningsbar alls, och ingen .po-fil kan nå den. De flesta välrenommerade plugin omsluter allt korrekt, men om du märker en eller två envisa strängar som vägrar att översättas, är en saknad Gettext-omslutning i källkoden en trolig orsak.

Ett snabbt sätt att bedöma om ett plugin verkligen är översättningsklart är att kontrollera dess listning i WordPress.org-katalogen, som visar en översättningsprocent och länkar till en /languages-mall. Ett plugin med ett aktivt översättningsprojekt är betydligt mer sannolikt att ha rena, helt omslutna strängar än ett övergivet.

Vad händer om pluginet inte har någon .pot-fil?

Vissa plugin levereras utan en .pot-mall. Om /languages-mappen är tom eller saknas måste du generera mallen själv genom att skanna källkoden efter översättningsbara strängar.

Standardverktyget för detta är WP-CLI, som extraherar varje Gettext-anrop till en ny .pot.

wp i18n make-pot wp-content/plugins/awesome-plugin \
  wp-content/plugins/awesome-plugin/languages/awesome-plugin.pot

Detta kommando går igenom pluginets .php- och JavaScript-filer, hittar varje __(), _e(), _n() och relaterade anrop, och skriver en komplett mall. Om du föredrar en grafisk väg kan Poedit Pro skanna källkod på samma sätt. Hur som helst är resultatet en .pot som innehåller alla källsträngar med tomma översättningar, redo att omvandlas till en riktig språkfil.

Att generera din egen mall har en dold fördel: den fångar upp strängar som den ursprungliga utvecklaren kan ha glömt att inkludera i en levererad .pot-fil. Plugin utvecklas snabbt, och en mall som följde med version 2.1 kanske saknar strängar som lades till i 2.4. Att återskapa från den nuvarande källkoden garanterar att din katalog återspeglar vad pluginet faktiskt visar idag, inte vad det visade för två utgåvor sedan. Om du underhåller översättningar för ett plugin över tid, är det en pålitlig vana att köra make-pot igen efter varje större uppdatering.

Skapa .po- och .mo-filer med korrekt namn

Det vanligaste misstaget när man översätter ett plugin är filnamnet. WordPress hittar plugin-översättningar genom att matcha ett mycket specifikt mönster, och ett felaktigt tecken innebär att din översättning ignoreras helt.

Filnamnsformeln

För plugin-översättningar är mönstret text-domain-locale. Så för textdomänen awesome-plugin översatt till tyska, måste filerna namnges:

awesome-plugin-de_DE.po
awesome-plugin-de_DE.mo

Språkkoden är WordPress webbplatsspråkskod: de_DE för tyska, fr_FR för franska, es_ES för spanska, pt_BR för brasiliansk portugisiska. Om du får fel språkkod hoppar WordPress tyst över din fil. Du skapar dessa från .pot-mallen i en redigerare som Poedit, som automatiskt kompilerar den binära .mo-filen när du sparar. Om du är ny med den redigeraren, går den kompletta Poedit-guiden igenom hur du skapar en översättning från en mall steg för steg.

Var du ska placera filerna så att uppdateringar inte raderar dem

Det finns två möjliga platser, och att välja rätt spelar roll.

# RISKY: inside the plugin — wiped on every plugin update
wp-content/plugins/awesome-plugin/languages/awesome-plugin-de_DE.mo

# SAFE: the global languages override folder — survives updates
wp-content/languages/plugins/awesome-plugin-de_DE.mo

Använd alltid wp-content/languages/plugins/. WordPress kontrollerar denna åsidosättningskatalog först, och eftersom den ligger utanför plugin-mappen rör en uppdatering av pluginet aldrig dina översättningar. Filer som placeras i pluginets egen mapp skrivs över i samma ögonblick som en ny version installeras.

Detta åsidosättningsbeteende är en av de mest användbara och minst kända funktionerna i WordPress-lokalisering. Det betyder att du kan leverera anpassade eller korrigerade översättningar för alla tredjepartsplugin utan att någonsin ”forka” det, och dina ändringar är helt uppdateringssäkra. Om du hanterar flera klientwebbplatser som kör samma plugin kan du till och med ha en enda uppsättning .mo-filer för åsidosättningar och distribuera dem till alla, med vetskapen om att varje webbplats automatiskt kommer att plocka upp dem så länge språkkoden matchar.

Hur WordPress laddar din översättning

Ett översättningsklart plugin instruerar WordPress att ladda sin katalog genom att anropa load_plugin_textdomain() under initieringen:

add_action( 'init', function() {
    load_plugin_textdomain(
        'awesome-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages'
    );
} );

För de flesta moderna plugin på WordPress 4.6 och senare behöver du inte röra detta. WordPress laddar automatiskt översättningar från wp-content/languages/plugins/ så länge ditt filnamn och webbplatsens språkkod matchar. Om din färdiga översättning fortfarande inte visas, är orsaken nästan alltid ett felaktigt filnamn, en föråldrad .mo-fil, eller att webbplatsens språk är inställt på fel språkkod. Vår felsökningsguide för översättningar som inte visas går igenom var och en av dessa felpunkter.

Plugin som lagrar strängar i databasen

Här är den viktiga begränsningen. Gettext-metoden översätter endast strängar som finns i pluginets kod. Vissa plugin, särskilt formulärbyggare, sidbyggare och e-handelsutökningar, låter dig skapa innehåll (formulärfält, produktattribut, anpassade meddelanden) som sparas i WordPress-databasen. Dessa strängar är användargenererade data, inte en del av .pot-filen, så en .po-fil kan inte nå dem. För databasinnehåll behöver du ett flerspråkigt plugin som WPML eller Polylang, eller pluginets egen strängöversättningsfunktion. Testa alltid om en given sträng finns i koden eller i databasen innan du antar att en .po-fil kan åtgärda den.

Ett enkelt test talar om vilken typ av sträng du har att göra med. Om texten är något du har skrivit in i ett inställningsfält, en formuläretikett du har skapat, ett anpassat tackmeddelande, ett produktnamn, är det databasinnehåll och en .po-fil kan inte påverka det. Om texten är en del av pluginets inbyggda gränssnitt, knappetiketter, valideringsfel, adminmeddelanden som levereras med själva pluginet, finns det i koden och en .po-fil är exakt rätt verktyg. Att dra denna gräns tidigt sparar timmar av frustration, eftersom ingen mängd perfekt .po-redigering någonsin kommer att översätta en sträng som pluginet hämtar från databasen vid körning.

Översätta i stor skala utan det manuella arbetet

Att översätta ett plugin till ett språk för hand är hanterbart. Att översätta det till tio språk, eller att översätta en hel uppsättning plugin för en klientwebbplats, blir dagar av repetitivt arbete, och varje manuell redigering riskerar att man fumlar med en platshållare som %s eller %1$s och förstör utdata.

Det är här ett molnbaserat arbetsflöde ändrar förutsättningarna. Ladda upp pluginets .po eller .pot till SimplePoTranslate, välj dina målspråk, och kontextmedveten AI översätter hela katalogen medan Syntax Locking fryser varje platshållare, HTML-tagg och kodtoken så att inget kan gå sönder. Smart Batching hanterar stora kataloger i ett enda svep, och du laddar ner en ZIP som innehåller .po, .mo, .json, .php och .xliff tillsammans, korrekt formaterade och redo att släppas in i wp-content/languages/plugins/. Det körs helt i molnet, så det finns ingen skrivbordsinstallation och ingen bloat på din webbplats.

Observera att översättning av ett plugin skiljer sig från översättning av ett tema, som använder en något annorlunda mappkonvention och laddningsfunktion. Om ett tema är ditt mål, följ istället vår dedikerade guide om hur du lokaliserar vilket WordPress-tema som helst även om du inte är utvecklare.

Använd den manuella vägen när du har ett plugin och ett språk. Använd molnet när du behöver många språk, snabbt, utan att kompromissa med platshållarsäkerheten.

Redo att översätta ditt WordPress-plugin till alla språk din publik talar utan att bryta en enda variabel? Prova SimplePoTranslate gratis — inget kreditkort krävs. Den kostnadsfria nivån låter dig översätta din första .po-fil för ett plugin på några minuter, med Syntax Locking på varje sträng.