Sådan oversætter du et WordPress-plugin (trin for trin)

Du har fundet det perfekte WordPress-plugin til dit projekt. Det gør præcis, hvad du har brug for, anmeldelserne er strålende, og så aktiverer du det og indser, at hver knap, etiket og fejlmeddelelse er på engelsk. Dine tyske, franske eller japanske besøgende er lige ved at ramme en mur af tekst, de ikke kan læse.

Den gode nyhed er, at de fleste vellavede plugins er klar til oversættelse, hvilket betyder, at udvikleren har pakket deres strenge ind i Gettext-funktioner specifikt, så folk som dig kan oversætte dem. Udfordringen er at vide, hvor filerne ligger, hvad du skal kalde din oversættelse, og hvor du skal placere den, så den næste plugin-opdatering ikke sletter dit arbejde.

Denne guide viser dig, hvordan du oversætter et WordPress-plugin fra start til slut: at finde tekstdomænet og sprogmappen, få eller generere .pot-skabelonen, bygge korrekt navngivne .po- og .mo-filer og placere dem, hvor WordPress pålideligt vil indlæse dem. Vi vil også dække den ene type plugin, som denne tilgang ikke fuldt ud kan oversætte, så du ikke spilder timer på at kæmpe en umulig kamp.

Hvordan finder du et plugins oversættelsesfiler?

Før du oversætter noget, har du brug for to oplysninger fra pluginnet: dets tekstdomæne og dets sprogmappe. Tekstdomænet er den unikke streng, pluginnet bruger til at identificere sine egne oversættelser, og sprogmappen er der, hvor kildeskabelonen ligger.

Lokalisering af sprogmappen og tekstdomænet

Åbn pluginmappen på wp-content/plugins/your-plugin/ og kig efter en /languages undermappe. Inde i den finder du normalt en .pot-fil, den tomme skabelon, der indeholder alle oversættelige strenge.

For at bekræfte tekstdomænet skal du åbne pluginets hoved-.php-fil og se på dets headerblok:

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

Her er tekstdomænet awesome-plugin. Denne værdi er kritisk, fordi dine oversættelsesfiler skal inkludere den i deres navne, ellers vil WordPress aldrig matche dem med pluginnet. Du vil også se den i hvert strengkald i hele koden:

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

Det andet argument, awesome-plugin, er tekstdomænet igen. Hver streng, der bruger det, kan oversættes af dit katalog. Hvis en streng i pluginets grænseflade mangler denne wrapper, for eksempel en udvikler, der hardkodede echo 'Save' uden __(), så kan strengen slet ikke oversættes, og ingen .po-fil kan nå den. De fleste anerkendte plugins pakker alt korrekt ind, men hvis du bemærker en en eller to stædige strenge, der nægter at oversætte, er en manglende Gettext-wrapper i kilden en sandsynlig synder.

En hurtig måde at vurdere, om et plugin virkelig er klar til oversættelse, er at tjekke dets oversigt i WordPress.org-mappen, som viser en oversættelsesprocent og linker til en /languages-skabelon. Et plugin med et aktivt oversættelsesprojekt er langt mere sandsynligt at have rene, fuldt indpakkede strenge end et forladt.

Hvad hvis pluginnet ikke har en .POT-fil?

Nogle plugins leveres uden en .pot-skabelon. Hvis /languages-mappen er tom eller mangler, skal du selv generere skabelonen ved at scanne kildekoden efter oversættelige strenge.

Standardværktøjet til dette er WP-CLI, som udtrækker hvert Gettext-kald til en frisk .pot-fil.

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

Denne kommando gennemgår pluginets .PHP- og .JavaScript-filer, finder hvert __(), _e(), _n() og relaterede kald og skriver en komplet skabelon. Hvis du foretrækker en grafisk tilgang, kan Poedit Pro scanne kildekode på samme måde. Uanset hvad er resultatet en .pot-fil, der indeholder alle kildestrenge med tomme oversættelser, klar til at blive omdannet til en rigtig sprogfil.

At generere din egen skabelon har en skjult fordel: den fanger strenge, som den oprindelige udvikler muligvis har glemt at inkludere i en leveret .pot-fil. Plugins udvikler sig hurtigt, og en skabelon, der fulgte med version 2.1, mangler muligvis strenge tilføjet i 2.4. Regenerering fra den nuværende kilde garanterer, at dit katalog afspejler, hvad pluginnet faktisk viser i dag, ikke hvad det viste for to udgivelser siden. Hvis du vedligeholder oversættelser for et plugin over tid, er det en pålidelig vane at køre make-pot igen efter hver større opdatering.

Oprettelse af PO- og MO-filer med det korrekte navn

Den mest almindelige fejl, når man oversætter et plugin, er filnavnet. WordPress finder plugin-oversættelser ved at matche et meget specifikt mønster, og et forkert tegn betyder, at din oversættelse ignoreres fuldstændigt.

Filnavnsformlen

For plugin-oversættelser er mønstret text-domain-locale. Så for tekstdomænet awesome-plugin, oversat til tysk, skal filerne navngives:

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

Landekoden er WordPress-sidens sprogkode: de_DE for tysk, fr_FR for fransk, es_ES for spansk, pt_BR for brasiliansk portugisisk. Får du landekoden forkert, springer WordPress stille og roligt din fil over. Du opretter disse fra .pot-skabelonen i en editor som Poedit, som automatisk kompilerer den binære .mo-fil, når du gemmer. Hvis du er ny til den editor, gennemgår den komplette Poedit-guide trin for trin, hvordan du opretter en oversættelse fra en skabelon.

Hvor skal filerne placeres, så opdateringer ikke sletter dem

Der er to mulige placeringer, og det er vigtigt at vælge den rigtige.

# 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

Brug altid wp-content/languages/plugins/. WordPress tjekker først denne tilsidesættelsesmappe, og fordi den ligger uden for plugin-mappen, rører opdatering af pluginnet aldrig dine oversættelser. Filer placeret inde i pluginets egen mappe bliver overskrevet, så snart en ny version installeres.

Denne tilsidesættelsesadfærd er en af de mest nyttige og mindst kendte funktioner i WordPress-lokalisering. Det betyder, at du kan levere brugerdefinerede eller korrigerede oversættelser til ethvert tredjeparts-plugin uden nogensinde at forke det, og dine ændringer er fuldstændig opdateringssikre. Hvis du administrerer flere klientwebsteder, der kører det samme plugin, kan du endda opbevare et enkelt sæt tilsidesættelses-.mo-filer og implementere dem på tværs af dem alle, velvidende at hvert websted automatisk vil hente dem, så længe landekoden stemmer overens.

Hvordan WordPress indlæser din oversættelse

Et oversættelsesklart plugin beder WordPress om at indlæse dets katalog ved at kalde load_plugin_textdomain() under initialisering:

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

For de fleste moderne plugins på WordPress 4.6 og nyere behøver du ikke at røre ved dette. WordPress indlæser automatisk oversættelser fra wp-content/languages/plugins/, så længe dit filnavn og webstedets landekode stemmer overens. Hvis din færdige oversættelse stadig ikke vises, er årsagen næsten altid et forkert filnavn, en forældet .mo-fil eller et webstedssprog indstillet til den forkerte landekode. Vores fejlfindingsguide til oversættelser, der ikke vises, gennemgår hvert af disse fejlpunkter.

Plugins, der gemmer strenge i databasen

Her er den vigtige begrænsning. Gettext-tilgangen oversætter kun strenge, der findes i pluginets kode. Nogle plugins, især formularbyggere, sidebyggere og e-handelsudvidelser, lader dig oprette indhold (formularfelter, produktattributter, brugerdefinerede meddelelser), der gemmes i WordPress-databasen. Disse strenge er brugergenererede data, ikke en del af .pot-filen, så en .po-fil kan ikke nå dem. Til databaseindhold har du brug for et flersproget plugin som WPML eller Polylang, eller pluginets egen strengoversættelsesfunktion. Test altid, om en given streng findes i koden eller i databasen, før du antager, at en .po-fil kan rette det.

En simpel test fortæller dig, hvilken slags streng du har at gøre med. Hvis teksten er noget, du har indtastet i et indstillingsfelt, en formularfelt du har oprettet, en brugerdefineret takkebesked, et produktnavn, er det databaseindhold, og en .po-fil kan ikke røre det. Hvis teksten er en del af pluginets indbyggede grænseflade, knapetiketter, valideringsfejl, admin-meddelelser, der følger med selve pluginnet, findes det i koden, og en .po-fil er præcis det rigtige værktøj. At trække denne grænse tidligt sparer timer af frustration, for ingen mængde perfekt .po-redigering vil nogensinde oversætte en streng, som pluginnet trækker fra databasen under kørsel.

Oversættelse i stor skala uden det manuelle slid

At oversætte et plugin til ét sprog i hånden er overskueligt. At oversætte det til ti sprog, eller at oversætte en hel stak plugins for et klientwebsted, forvandles til dages gentaget arbejde, og hver manuel redigering risikerer at kludre i en pladsholder som %s eller %1$s og ødelægge outputtet.

Det er her, en cloud-workflow ændrer regnestykket. Upload pluginets .po- eller .pot-fil til SimplePoTranslate, vælg dine målsprog, og kontekstfølsom AI oversætter hele kataloget, mens Syntax Locking fastfryser hver pladsholder, HTML-tag og kodetoken, så intet kan gå i stykker. Smart Batching håndterer store kataloger i en enkelt omgang, og du downloader en ZIP-fil, der indeholder .po, .mo, .json, .php og .xliff samlet, korrekt formateret og klar til at blive placeret i wp-content/languages/plugins/. Det kører udelukkende i skyen, så der er ingen desktop-installation og ingen bloat på dit websted.

Bemærk, at oversættelse af et plugin adskiller sig fra oversættelse af et tema, som bruger en lidt anderledes mappekonvention og indlæsningsfunktion. Hvis et tema er dit mål, følg i stedet vores dedikerede guide om lokalisering af ethvert WordPress-tema, selvom du ikke er udvikler.

Brug den manuelle metode, når du har et plugin og ét sprog. Brug skyen, når du hurtigt har brug for mange sprog, uden at gå på kompromis med pladsholderens sikkerhed.

Klar til at oversætte dit WordPress-plugin til alle sprog, dit publikum taler, uden at ødelægge en eneste variabel? Prøv SimplePoTranslate gratis — intet kreditkort påkrævet. Den gratis plan lader dig oversætte din første plugin-.po-fil på få minutter, med Syntax Locking på hver streng.