Vad WordPress i18n är och varför det spelar roll: Här är allt du behöver veta!

För den som inte är medveten om det: WordPress är kärnan i nästan 43 procent av världens webbplatser. Dessutom finns Content Management System (CMS) tillgängligt på 205 olika platser. Eftersom plattformen är en global enhet är lokalisering viktig. WordPress i18n-processen är nyckeln till detta.

Det som lockar med i18n är att det är ett sätt att förbereda din tema- och plugin-kod för översättning. Därefter kan du använda korrekta översättningar till andra språk, anpassa dig till andra kulturer och platser och dra nytta av fördelarna.

I det här inlägget kommer vi att diskutera WordPress i18n mer i detalj och visa dig hur du använder det. Även om du vill ha viss kodningskunskap, kommer vi också att diskutera stegen i detalj - tillsammans med vad WordPress i18n är (och gör).

Vad i18n står för

"Leet speak" är en produkt från en svunnen tid och lever i allra högsta grad kvar i webbutvecklingskretsar. Även om du inte kommer att se mycket av "l33t" och "n00b", kommer du att se massor av numeronymer: a11y när diskussionen handlar om tillgänglighet, till exempel.

Faktum är att i18n är en annan numeronym. Den står för "internationalisering" och består av den första och sista bokstaven i kombination med ett tal som anger hur många bokstäver som finns däremellan. Du kommer också att upptäcka att lokalisering har sin egen numeronym: l10n. Det finns också andra numeronymer, till exempel globalisering (g11n), europeisering (e13n) och många fler.

Här ska vi titta specifikt på internationalisering. Den officiella briefen från World Wide Web Consortium (W3C) konstaterar att det här är där design och utveckling möjliggör enkel lokalisering för användare av olika kulturer, platser, språk och mer.

Det är viktigt att notera att internationalisering bara är ett första steg i översättningsprocessen. Därefter genomför du lokaliseringen med hjälp av en lämplig översättningslösning.

Grunderna i i18n-lokaliseringsprocessen

För själva i18n-processen finns det ett antal steg som WordPress-utvecklaren kommer att ta innan de överlämnar till översättaren. I ett nötskal går lokaliseringsprocessen till på följande sätt:

• Lägg till en "text domain"-tagg i sidhuvudet.
• Ladda en språkfil med hjälp av några dedikerade WordPress-funktioner.
• "Märka upp" textsträngar med hjälp av "gettext"-funktioner (vi ska tala om detta om en liten stund).
• Generera enPOT-fil(Portable Object Template) för ditt tema eller plugin och inkludera den.
• Du kanske vill skapa en CSS-fil (Cascading StyleSheets) för RTL-tal (Right-To-Left).

Översättaren tar .pot-filen och använder den för att utföra lokaliseringen, så det är en viktig del av proceduren.

En kort introduktion till verktyget gettext

För den som inte känner till det är POT-filer ett exempel på filer som genereras med hjälp av GNU:s gettextverktyg. Detta är teknik och programvara från 1980-talet som fortfarande erbjuder ett enormt värde för dem som utför i18n idag.

Att veta exakt vad det här är är inte nödvändigt för att utföra WordPress i18n, men det är användbart att förstå vad det gör i allmän mening och vad det genererar. Betrakta gettext som ett ramverk som hjälper WordPress att producera flerspråkiga meddelanden.

Du kommer ofta att se ett antal filer associerade med gettext:

• POT-filer. Detta är mallen för dina i18n-insatser och det är vad översättaren använder för att starta sin del av processen.
• Portable Object (PO)-filer. I praktiken är det ingen större skillnad mellan POT- och PO-filer. Under översättningen kommer PO-filen att innehålla textsträngar på både modersmålet och det översatta språket.
• Maskinobjekt (MO)-filer. Betrakta MO-filer som den WordPress-kodvänliga versionen av en PO-fil. Den kommer att ligga i tema- eller plugin-katalogen i din installation och kommer att tillhandahålla översättningarna när WordPress behöver dem.

Med allt detta i åtanke kan du nästan påbörja i18n-processen. Först är det bra att förbereda din WordPress sida för det kommande arbetet.

Innan du börjar genomföra WordPress i18n-processen

Som med alla projekt som rör WordPress kärnfiler vill du se till att din installation är "ren" innan du börjar. Du bör också se till att du kan återställa alla ändringar du gör, om det värsta scenariot skulle inträffa och du behöver återställa.

Därför finns det två nästan icke förhandlingsbara "försteg" före i18n-processen:

• Gör en fullständig säkerhetskopia av din webbplats. Detta borde vara en självklarhet eftersom en fullständig säkerhetskopia är det enda sättet att skydda din webbplats om du behöver börja om igen.
• Genomför en plugin-granskning. Det är en bra idé att ta en titt på alla plugins som din webbplats har och fundera över två frågor: Finns det en uppdatering tillgänglig, och behöver jag pluginet?

I det senare fallet rekommenderar vi att du uppdaterar de plugins du vill behålla och tar bort de som inte längre behövs.

Återigen kommer vi att arbeta i dina WordPress-kärnfiler, så du bör ha kunskap om hur dessa fungerar och vad de innehåller. Vissa av de begrepp som vi kommer att prata om i handledningen kommer inte nödvändigtvis att ha en förklaring, även om stegen i sig kommer att ha det.

När alla dessa punkter är klara kan du börja arbeta med i18n-processen.

Så här genomför du WordPress i18n-processen med dina teman och plugins

Under de kommande avsnitten kommer vi att visa dig hur du genomför WordPress i18n med dina teman och plugins. Även om varje avsnitt kan vara kodtungt och tekniskt på sina ställen, kommer vi att förklara allt så noggrant som möjligt och länka till ytterligare resurser som du kan behöva.

Vi börjar med hur du internationaliserar dina teman.

Så här skapar du ett översättningsbart WordPress-tema

Det första steget är att uppdatera temats header så att den innehåller en textdomän och en domänväg. Kort och gott:

• Textdomänen hjälper WordPress att förstå vilka strängar som "hör till" temat. Detta måste matcha ditt temas (och plugins) slug.
• Domänsökvägen är den mapp i ditt temas filer där översättningsfilerna kommer att "bo". Katalogen /languages/ är det typiska och förvalda namnet, men du kan använda något annat om du behöver.

För att göra detta behöver du bara lägga till några ord i temats header-fil:

/*
Theme Name: Mitt anpassade tema
Författare: Weglot Translate
Text Domain: my-theme
Domain Path: /språk/
*/‍

Därefter måste du ladda den textdomänen med hjälp av en "action" och en "function":

add_action( 'after_setup_theme', 'my_theme_setup' );
function my_theme_setup() {
load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
}‍

Den här kodsviten måste finnas i ditt temas functions.php-fil, snarare än på din webbplats. När du har gjort detta kan du börja utföra en "stränggranskning". Detta kräver att du slår in alla textsträngar i ditt tema i översättningsfunktioner. Det finns två funktioner som du kommer att använda ofta:

• __(). Detta inkluderar ett dubbelt understreck (eller "dunder") och returnerar en översatt sträng.
• _e(). Detta ekar (eller skriver ut) den översatta strängen som den presenteras.

Dessa funktioner kräver två argument: textsträngen och textdomänen. Till exempel

__()
$welcome = __( 'Hej! Välkommen till instrumentpanelen!', 'my-theme' );
_e( 'Hej igen!', 'my-theme' );‍

Även om de olika översättningsfunktionerna ligger utanför ramen för den här artikeln, innehåller WordPress Theme Developers' Handbook nästan all information du behöver för att göra jobbet.

I det här läget kan du skapa en POT-fil. Det finns många lösningar för att göra detta, men WordPress rekommenderar Poedit - en gratis lösning med öppen källkod.

När du har laddat ner och installerat Poedit går du till Arkiv > Ny i verktygsfältet:

Skapa sedan en ny katalog. Du kan klicka på länken Extrahera från källor på huvudskärmen:

Fyll sedan i fälten för projektnamn, språkteam och primärspråk på fliken Translation Properties:

Om filen är ny vill du spara den här (filnamnet bör vara detsamma som ditt temas slug). Välj sedan fliken Sources Paths och leta reda på mappen /languages/ på din dator:

Den sista fliken Sources Keywords kommer att innehålla en lista över de översättningsfunktioner som du har använt i ditt tema:

Du kommer att vilja lägga till dem här, även om det kan vara svårt att hitta rätt nyckelord. Som en början kan du använda följande lista:

__
_e
_x
_ex
_n
_nx
_n_noop
_nx_noop
translate_nooped_plural
number_format_i18n
date_i18n
esc_html__
esc_html__
esc_html_x
esc_attr__
esc_attr_e
esc_attr_x‍

När du klickar för att bekräfta, spara dina ändringar och kolla in dina nya filer: du ser MO- och PO-filer på din dator. Om du duplicerar PO-filen kan du lägga till POT-tillägget, och härifrån kan du gå vidare till lokalisering.

Så här skapar du ett översättningsbart WordPress-plugin

Din första uppgift här liknar ett tema: uppdatera först pluginets textdomän och domänsökvägsfält i sidhuvudet:

/*
Pluginets namn: My Custom Plugin
Plugin URI:weglot
Beskrivning: Ett anpassat plugin för att visa upp översättning och i18n.
Författare: Weglot Translate
Version: 1.0
Author URI:weglot
Text Domain: my-plugin
Domain Path: /språk/
*/‍

Vi rekommenderar att du skapar en /languages/-mapp för domänsökvägen och ställer in denna som domänsökväg. Därifrån kan du ladda textdomänen för plugin-programmet, men den här gången kan du lägga till följande funktion i din kod, snarare än via functions.php:

load_plugin_textdomain( $domain, $abs_rel_path, $plugin_rel_path );‍

Detta låter dock bara WordPress veta att det finns en översättningsfil tillgänglig. För att ladda den måste du paketera funktionen i en åtgärd:

add_action( 'plugins_loaded', 'plugin_load_td' );‍function plugin_load_td() {
load_plugin_textdomain( 'my-plugin', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
}‍

Mycket av stränggranskningen kommer att likna tema i18n. Det sista steget är att generera en POT-fil med samma process som tidigare; den genererade filen kommer att hamna i den aktuella arbetskatalogen

Vilka är begränsningarna med WordPress i18n?

Vid det här laget förstår du säkert hur fantastiskt WordPress i18n kan vara. Det är fantastiskt om du utvecklar teman eller plugins och vill göra dem redo att översättas. Men som med alla bra saker finns det också vissa nackdelar.

Om ett insticksprogram innehåller användargenererat innehåll kommer det till exempel inte att ingå i i18n-översättningen.

i18n-processen möjliggör översättningar för statiska element som du kodar, t.ex. knapptext. Men om användaren vill ange en specifik fras för ett fält, skapa unika etiketter och andra element på klientsidan kommer du inte att kunna ta hänsyn till dessa. Det skulle du faktiskt kunna göra, men det är en komplex uppgift som ligger utanför ramen för ett inlägg som detta.

Om du inte är utvecklare kommer i18n inte heller att hjälpa dig att översätta din webbplats. För detta behöver du ett plugin, och du kanske vill hoppa vidare till nästa avsnitt för ett lämpligt alternativ.

Det är också värt att notera att även om översättningsplugins kan hjälpa till på många sätt, behöver en webbplats i genomsnitt fem plugins för att vara flerspråkig i sin helhet. Däremot är en lösning som Weglot är snabb att arbeta, kan upptäcka alla de översättningsbara delarna av en webbplats och är kompatibel med nästan alla teman och plugin. Detta oavsett om dessa teman och plugins är redo att översättas.

Dessutom använder Weglot temat, plugin och huvudinnehållselementen från den främre HTML-sidan och gör dem översättningsbara. Därför finns det inga .pot- och .po-filer, och gettext-metoden är inte heller nödvändig.

Hur Weglot stöder WordPress i18n

I tekniska termer ska vi nu diskutera lokaliseringen av ditt innehåll - direktöversättningsprocessen.

Det är inte lätt att ha en bra översättningsstrategi. Det är hårt arbete och kräver mycket planering för att se till att ditt innehåll når ut till olika kulturer, platser och språk på rätt sätt. Det handlar inte bara om den översatta texten i innehållets brödtext. Du måste också ta hänsyn till allt det följande:

• De vackra permalänkar du använder.
• Metadata för inlägg och sidor.
• Media, t .ex. bilder, videor, GIF-filer, ikoner och annat - inklusive tillhörande metadata.

Om du använder e-handel finns det också en mängd saker att tänka på här. Du bör till exempel se till att din kassaskärm erbjuder en fullständig översättning av alla element – särskilt fälten för valuta och skatt:

Fraktinformation är dessutom en viktig aspekt att översätta fullständigt och med hög kvalitet. Du vill att kunderna inte ska ha någon ursäkt för att klicka på Köp-knappen, oavsett vilket språk du använder.

Weglot gör en hel del av det tunga arbetet åt dig. Det är en värdefull allierad för dina WordPress i18n-ansträngningar eftersom det upptäcker alla aspekter av din webbplats som du kan översätta. Därifrån kommer det att utföra ett första lager av maskinöversättning åt dig:

Detta kan vara tillräckligt för dina behov, men Weglot kan hjälpa dig att gå ett steg längre. Du kan ta in professionella översättningar, redigera befintliga översättningar och mycket mer. Detta ger dig all den flexibilitet du behöver för att genomföra en fullständig lokalisering av din webbplats.

Slutsats

WordPress finns nästan överallt i världen. Därför är internationaliserade teman och plugins till stor hjälp när de ska översättas till andra språk. WordPress i18n är en viktig kugge i hjulet för utvecklare som arbetar med plattformen.

Om du kan internationalisera ditt tema för att hjälpa användare att skapa översättningar utan att ändra källkoden har du ett bra utgångsläge. Men bara för att du tillämpar i18n-koncept betyder det inte att ditt tema eller plugin är översatt.

För att utföra detta steg vill du lita på en lösning som Weglot. Den är kompatibel med många olika plattformar och tekniker och fungerar fantastiskt med WordPress. När du har slutfört i18n-delen av ditt arbetsflöde kan du vända dig till Weglot för att generera exakta och enkla att implementera översättningar på nästan alla språk.

För att ta reda på det själv erbjuder Weglot en 10-dagars gratis provperiod utan skyldighet att köpa.