Met WordPress-plug-ins kun je eenvoudig je blog aanpassen en verbeteren door nieuwe functionaliteit te bieden die anders niet beschikbaar is in de basiscode.

Het gebruik van plug-ins werkt effectiever dan proberen de algehele kernprogrammering van WordPress te wijzigen. Gedefinieerd als een programma of een reeks functies geschreven in PHP, voegen plug-ins specifieke functies toe die eenvoudig kunnen worden geïntegreerd met de blog via de WordPress API.

Als u een WordPress-plug-in hebt geschreven, kunt u deze veel beter toegankelijk maken door deze in een andere taal te vertalen. Dit staat bekend als internationalisering.

Internationalisering versus lokalisatie

Voordat u uw plug-in kunt internationaliseren, moet u weten wat het betekent. Dit wordt ook wel i18n genoemd. Dit betekent dat de plug-in moet worden aangepast, zodat andere culturen die andere talen spreken, gemakkelijk uw plug-in kunnen gebruiken.

Lokalisatie daarentegen is het feitelijke proces van modificatie.

Er is meer bij internationalisering dan alleen het vertalen van de interface. Bijvoorbeeld, aannames die je hebt gemaakt over imperiale eenheden en metrische eenheden, interpunctie zoals het gebruik van een komma om duizenden te scheiden in plaats van een punt, en andere culturele onderwerpen moeten worden aangepakt voordat je je werk goed kunt lokaliseren.

Hoewel dit een gids is die de voorbereiding van het lokaliseren van een plug-in behandelt, is het nog steeds belangrijk om deze extra aanpassingen in gedachten te houden.

Domeinen en initialisatie

Het lokaliseren van uw plug-in betekent dat u een tekstdomein moet maken, waarbij elke tekst apart moet worden gehouden van degene die WordPress gebruikt of die andere plug-ins hebben gedefinieerd. Wat je ook voor een tekstdomein wilt gebruiken, is aan jou, maar je zult iets unieks en verstandigs willen kiezen, gerelateerd aan waar je plugin over gaat.

Voordat u uw plug-in volledig kunt lokaliseren, moet u hem aan WordPress laten weten hoe hij uw strings kan vinden. Als de code nog niet bestaat, moet u iets als de volgende regel in uw codering invoegen:

add_action( 'init', 'myFunction' );

Deze code communiceert met WordPress om hem te vertellen de functie myFunction te gebruiken zodra deze wordt geladen. Deze functie benoemt vervolgens uw tekstdomein naar WordPress en leert hoe het de gelokaliseerde tekenreeksen kan laden, die er ongeveer zo uitzien:

function myFunction() {load_plugin_textdomain( 'mytextdomain', 'wp-content/plugins' );}

De WordPress-functie load_plugin_textdomain informeert WordPress dat er een tekstdomein is met de naam mytextdomain en dat de bestanden met de gelokaliseerde tekenreeksen zich binnen de servermap wp-content / plugin bevinden. (Natuurlijk, als u uw plug-in-bestanden in een andere map en pad plaatst, moet u dit vervangen door het juiste pad.)

Flags

Internationaal imago via Shutterstock.

Snaren voorbereiden

Na de initialisatie moet u de statische tekenreeksen wijzigen in een functie waarmee WordPress de juiste gelokaliseerde versie van die reeks kan gebruiken. Het werkt immers niet goed om WordPress de verkeerde taal te laten trekken.

Deze functie biedt een korte naam die het gemakkelijk maakt om te internationaliseren: de double-underbar-functie _ (string, domein). De functie heeft twee parameters, waarbij de eerste de standaardstring is die de plug-in gebruikt als er geen gelokaliseerde versie beschikbaar is. De tweede parameter is hetzelfde tekstdomein dat u eerder in de code hebt geselecteerd.

Voorafgaand aan deze stap kan uw code er als volgt uitzien:

function addMyAdminPage() {add_options_page('A Page Title','A Menu Title',7, __FILE__, 'myAdminFunction' );}

Na het toevoegen van de code lijkt dit misschien zo:

function addMyAdminPage() {add_options_page(__( 'A Page Title', 'textdomain' ),__( 'A Menu Title', 'textdomain' ),7, __FILE__, 'myAdminFunction' );}
Flags

Internationaal imago via Shutterstock.

Localization

Met al je voorbereidingen uit de weg ben je eindelijk voorbereid op het daadwerkelijke proces van het omzetten van je WordPress-plug-in in meerdere talen.

Als u een lokalisatie voor uw plug-in wilt maken, moet u een .po-bestand maken met een naam die lijkt op de bestandsnaam van uw plug-in en de ISO 639-codes van 2 letters voor elk land en elke taal. Als uw plug-in bijvoorbeeld examplename heet en u deze naar het Spaans (Europees) wilt lokaliseren, wordt deze weergegeven als "examplename-es_ES.po".

Hoewel de WordPress codex tools biedt die kunnen helpen bij lokalisatie, is het vaak beter om gewoon met het .po-bestand van de ene plug-in als vertrekpunt te gaan. .po-bestanden zijn gemaakt van een enkele koptekst en vervolgens vertaalparen:

msgid "Options"msgstr "Opciones"

De msgid is de standaardreeks die verschijnt in de dubbele-balkenfunctie die u dicteert. Als het .po-bestand is gemaakt, kunt u een van de hulpmiddelen gebruiken die WordPress aanbiedt om een ​​.mo-bestand te maken, het andere bestand dat WordPress nodig heeft.

Andere vertalers helpen

Niemand kent elke taal, dus u wilt uw bronnen uitbreiden en andere mensen helpen met het vertalen naar andere talen. U moet echter een speciale procedure volgen om de benodigde bestanden te genereren voor uw vertalers, omdat u niet wilt dat ze uw broncode per ongeluk laten breken.

Het bestand dat u aan vertalers wilt geven, is een POT-bestand, dat er ongeveer zo uitziet:

#: wp-admin/admin-header.php:49msgid "Options"msgstr ""

Er zijn twee manieren om dit bestand te genereren. Als je je plug-in in de repository hebt geplaatst, ga je gewoon naar de admin-pagina en selecteer je "Generate POT file". Dit bestand is wat je naar vertalers stuurt zodat ze het kunnen lokaliseren, hoewel je waarschijnlijk je plug-in ermee wilt versturen, zodat vertalers je geen vragen over de plug-in hoeven te stellen.

Als u uw plug-in nog niet in de repository heeft, kunt u de WordPress I18n tools-map en gebruik het makepot.php script op de volgende manier:

php makepot.php wp-plugin the-plugin-directory

Houd er rekening mee dat u uw GNU-hulpprogramma voor internationalisatie op uw server moet installeren voordat u deze opdracht uitvoert.

Flags

Internationaal imago via Shutterstock.

testen

Met al uw gelokaliseerde bestanden op zijn plaats, is het tijd om ze uit te testen en te zien of er iets is dat u bent vergeten. Het testen van uw lokalisatie betekent dat u een eenvoudige regel in uw WordPress-configuratie moet veranderen om het te laten denken dat het een ander bestand zou moeten gebruiken. Wijzig het bestand wp-config en zoek de volgende regel:

define ('WPLANG', 'en_US');

Als deze regel niet eerder bestond, wil je nog een keer controleren of je installatie nog steeds goed werkt. Als dit het geval is, gaat u terug naar het bestand en wijzigt u de land- en taalcode. In het vorige voorbeeld zou dit als volgt zijn:

define ('WPLANG', 'es_ES');

Schakel ten slotte uw plug-in in om te testen hoe deze eruit ziet. Vergeet niet om terug te gaan naar uw oorspronkelijke standaardtaal als u klaar bent met testen.

Uw plug-in bijwerken

Met alle wijzigingen die WordPress in de loop van de tijd aanbrengt, is uw plug-in mogelijk niet volledig functioneel bij latere updates. Zorg ervoor dat je altijd de tijd neemt om je plug-in bij te werken waar mogelijk. Ervan uitgaande dat u het al hebt gehost in de WordPress Plugin Repository, kunt u enkele stappen ondernemen om nieuwe functies toe te voegen of patches bij te werken naar uw plug-in in de loop van de tijd. Je mag dit zo vaak doen als je wilt.

Wanneer u klaar bent met het bijwerken van uw plug-in en de laatste versie wilt vrijgeven, moet u een checklist in gedachten houden:

  • Test uw plug-in en garandeer dat de nieuwste versie echt goed werkt. Zorg ervoor dat u alle verschillende versies van WordPress in gedachten houdt en test ze uit met elke versie die mogelijk is. Test niet alleen nieuwe functies, want u kunt ook per ongeluk oudere functies verbreken.
  • Ga naar de trunk-map en wijzig de header-opmerking in het hoofd-PHP-bestand, zodat u het versienummer kunt bijwerken. Zorg ervoor dat u ook het versienummer wijzigt in het readme.txt-bestand in de stammap in het veld stabiele tag.
  • Het is altijd verstandig om nog een subsectie van het changeloggedeelte van het readme.txt-bestand te maken, zodat u kort kunt beschrijven wat er nieuw is in de nieuwste release in vergelijking met de vorige versie. Alles wat u hier invoert, wordt toegevoegd aan het tabblad Wijzigingslogboek op de pagina voor uw plug-in.
  • Zorg ervoor dat u een nieuwe SVN-tag maakt als onderdeel van de trunk.
  • Wacht een paar minuten tot het systeem de nieuwe wijzigingen registreert en ga vervolgens naar uw plugin-pagina en naar een blog waarop uw nieuwe plug-in is geïnstalleerd om te controleren of alles correct is bijgewerkt. Houd er rekening mee dat deze updatecontroles in de cache kunnen worden opgeslagen, dus het kan nodig zijn om iets langer te wachten voordat deze volledig is bijgewerkt.

Al met al is er niet veel anders om uw plug-in te internationaliseren in verschillende talen. Zolang u deze stappen zorgvuldig uitvoert, kunt u uw plug-in lokaliseren in zoveel verschillende talen als u wilt.

Heb je een WordPress-plug-in gelokaliseerd? Welke talen wenste men vaker? Laat het ons weten in de comments.