Internationalizing WordPress-projekt Ett praktiskt exempel, del 1

I denna serie tittar vi på hur vi internationaliserar våra WordPress-projekt. För dem som bara går med oss ​​rekommenderar jag starkt att du granskar det första inlägget i serien, eftersom vi tittar på alla funktioner som finns i WordPress för att hjälpa oss att internationalisera våra strängar.

Och även om det är användbart, hjälper det fortfarande inte att förklara vilken internationalisering som är. Som vi sa i det första inlägget:

Internationalisering är processen att utveckla ditt plugin så att det enkelt kan översättas till andra språk.

Med tanke på att WordPress driver ungefär 25% av webben och att webben inte är lokal i ditt ursprungsland, är det meningsfullt att se till att det arbete vi producerar kan översättas till andra platser.

För att vara tydlig gör det här inte betyder att du som utvecklare ansvarar för att översätta alla strängar i din kodbas till olika språk som dina kunder kan använda. Istället betyder det att du använder rätt API för att se till att någon annan kan komma med och tillhandahålla översättningar för dem.

Innan vi går längre, kom ihåg:

  • Internationalisering, ofta kallad i18n, är processen där vi bygger vår programvara så att den kan översättas.
  • Lokalisering är när vi tar internationaliserade strängar och sedan översätter dem till rätt språk.

Lätt nog att förstå just nu? Men det finns mycket information där ute för hur man gör det, och det kan vara verkligen svårt att skilja signalen från bruset, speciellt om du är ny för att göra detta.

Men det är det här den här serien av handledning syftar till att göra: för att du är beväpnad med allt du behöver veta för att kunna internationalisera ditt WordPress-projekt korrekt, förstå vad du gör och förstå hur man testar det.

Under de två följande artiklarna kommer vi att skapa ett enkelt plugin som är korrekt internationaliserat. Dessutom ska vi titta på varje bit av plugin som går in i internationalisering av kodbasen för att se till att vi förstår allt.

I nästa artikel tar vi en titt på ett av de verktyg som jag har hittat mest användbara för att lokalisera ditt arbete och hur man testar att lokaliseringen fungerar korrekt.

Med det sagt, låt oss gå vidare och komma igång.

Komma igång

För den här handledningen kommer jag att använda den senaste versionen av WordPress som är tillgänglig via Subversion. Om du har en lokal kopia av WordPress installerad och det är en ny version, så är det bra.

Om du vill bo på blödkanten, kan du kolla in den här guiden för att få den senaste versionen av koden.

I slutändan kommer det inte att påverka det arbete vi gör, men det är en möjlighet att sträcka ut dina utvecklingsfärdigheter lite.

Förbereder plugin

Med en lokal kopia av WordPress installerad på din maskin är du redo att börja arbeta med ett plugin. Observera att i den här handledningen ska vi bygga ett otroligt grundläggande plugin.

Syftet är inte att förstå hur man bygger ett plugin, eftersom vi har täckt det i andra kurser och i andra handledning; Det är dock att förstå de finare nyanser som går in i internationaliseringen av kodbasen så att du förstår vad det är som du gör när du fortsätter att gå vidare med det arbete du ska göra i nuvarande eller framtida projekt.

1. Skapa Plugin Directory och Bootstrap

Hitta först wp-content / plugins katalog och skapa en katalog som heter tutsplus-i18n. Det här är katalogen där vi ska lagra våra pluginfiler. Det är lämpligt namngivet Tuts + Internationalisering.

Fortsätt och skapa en enda fil i katalogen som ska användas för att starta plugin. Ring filen tutsplus-i18n.php.

Innan vi går längre måste vi bestämma vad det här pluginet ska göra. Vi vet att vi behöver visa något för användaren så att vi kan öva internationalisering (och lokalisering). Det betyder att det ska finnas en användargränssnittskomponent till plugin.

För det ändamålet, låt oss skapa ett enkelt plugin som introducerar ett nytt menyalternativ under Verktyg meny. Vi ringer upp undermenyobjektet Server Info, och vi använder data som är enkelt tillgängliga i PHP för att visa en skärm av innehåll på ett användarvänligt sätt.

Kanske kan det här användas för att skicka en debug-logg till en leverantör om något skulle gå fel med ett plugin.

2. Definiera plugin

Jag antar att du är bekant med hur man skapar ett grundläggande plugin. Om inte, har vi ett antal handledningar och kurser tillgängliga om hur man gör det (som redan nämnts). Codex har också lite information om hur man kommer igång också.

Om du inte är bekant med hur du gör det, rekommenderar jag att du checkar ut ovanstående resurser. Med det sagt, låt oss gå vidare och definiera grunderna för vårt plugin.

För att komma igång måste vi definiera pluginhuvudet. Öppna tutsplus-i18n.php och se till att den innehåller följande information:

När du är klar, spara filen och navigera till plugins skärm i WordPress. Där borde du se en post för plugin som du just skapat. 

Beviljas, det kommer inte göra någonting just nu, men du kan se att vi är på rätt spår. Observera dessutom att vi har lagt till en tagg som du inte ofta ser med WordPress-projekt, och det är det Text Domän märka. Det här är vad vi ska använda för att hjälpa till att internationalisera vårt plugin.

Här är specifika detaljer om den här taggen:

Om du översätter ett plugin eller ett tema måste du använda en textdomän för att ange all text som tillhör det plugin. Detta ökar bärbarheten och spelar bättre med redan befintliga WordPress-verktyg. Textdomänen måste matcha "slug" i plugin.

Självklart har vi definierat vår textdomän som tutsplus-i18n. Du får se det här som används under resten av kodbasen i resten av handledningen.

Slutligen glöm inte att se till att du uppdaterar Författare och Författare URI taggar som matchar ditt namn och din hemsida också.

3. Introducera menyposten

Det första vi vill göra är att införa ett undermenyobjekt till Verktyg meny. För att göra detta kommer vi dra nytta av add_submenu_page krok som erbjuds av WordPress.

Observera att vi använder __ () funktion som vi diskuterade i det första inlägget i denna handledning för att se till att menyalternativets text är korrekt internationaliserad för översättning. Observera också att den andra parametern som passerade in i funktionen är densamma som den textdomän som definieras i pluginens rubrik.

Nu är det inte tillräckligt. Om du har läst den länkade dokumentationen ovan vet du att vi också måste definiera en funktion som visar innehållet på sidan. I koden ovan har vi refererat till funktionen som tutsplus_i18n_display_submenu_page, men vi har inte definierat funktionen.

Låt oss fortsätta och göra det nu. Vi gör det enkelt så att plugin faktiskt kommer att utföras. Sidan kommer inte visa något, men plugin fortsätter att fungera.

Vid den här tiden kan du aktivera ditt plugin och titta på innehållet under Verktyg meny. Ingenting borde översättas vid denna tidpunkt; dock du skall se ett nytt menyalternativ.

Och när du klickar på objektet bör du se något liknande skärmen ovan. Det är tomt. Men det är okej, för i nästa avsnitt kommer vi faktiskt att lägga lite information på skärmen.

4. Lägg till pluginens skärm

Beroende på vilka andra plugins och vilken annan kod du har studerat när du arbetar med WordPress-plugins har du sett kod skriven på ett av två sätt (eller kanske båda sätten, verkligen) som det gäller att visa ett plugins skärm.

  1. Hela HTML-filen är hårdkodad i huvudprogrammets PHP-fil.
  2. HTML-filen ingår i en extern fil som ingår i den centrala PHP-filen.

Jag är ett fan av den senare eftersom jag tycker att det hjälper till att göra koden mer underhållbar. Så för det här exemplet ska vi följa det här tillvägagångssättet. Vid den här tiden skapar du en andra fil i din plugin-katalog och kallar den tutsplus-i18n-ui.php

Lägg sedan till följande kod i filen. Vi diskuterar det närmare efter att du har fått chansen att granska det.

 

$ val) // Ingång var okej. ?>

Observera här att vi skapar en tabell element som visar alla nycklar och värden som finns i PHP: s $ _SERVER samling. 

Kanske är de viktigaste sakerna att märka som vi använder esc_html_e () för våra internationaliseringsfunktioner, och vi använder moduloperatören för att hjälpa oss att ge några styling för skärmen.

5. Stil in plugin

Tekniskt, vid denna punkt kommer plugin att fungera. Låt oss ta det ett steg längre för att se till att skärmen ser lite snygg ut.

Skapa först tutsplus-i18n.css filen i roten till din plugin-katalog och lägg till följande kod:

# tutsplus-i18n-bord margin-top: 20px; gränsen: 1px solid #ccc; vaddering: 10px;  # tutsplus-i18n-bordet th font-size: 15px; höjd: 40px;  # tutsplus-i18n-bordspanel, # tutsplus-i18n-tabell tbody font-family: "Monaco", "Menlo", "Courier New", Monospace;  # tutsplus-i18n-tabell tbody td höjd: 30px; vaddering: 5px;  # tutsplus-i18n-tabell tbody tr.odd bakgrund: #fff;  

Därefter lägger du till en funktion i pluginsfilen som kommer att korrekt ange den här filen, men endast på Serverinformation skärm:

id) return;  wp_enqueue_style ('tutsplus-i18n-css', plugin_dir_url (__FILE__). '/tutsplus-i18n.css', array (), '1.0.0', 'all');  

Vid denna punkt borde pluggen ha en något snyggare bildskärm:

Nej, det här behövs inte, men det bidrar till att plugin ser lite mer läsbar ut i samband med vad vi gör.

Vad om objektorienterad programmering?

För dem som har följt mina kurser och mina tutorials vet du att jag föredrar att skriva min kod i objektorienterad programmering snarare än i procedurprogrammering.

När det gäller att undervisa ett nytt koncept försöker jag att fokusera en lektion så tydligt som möjligt. För det ändamålet finner jag ofta att det med hjälp av procedurprogrammering att lära sig något sådant skapar mindre förvirring än när man använder objektorienterad programmering.

Det innebär att objektorienterad programmering förutsätter att du har en klar förståelse av vissa begrepp som du kanske inte har när du går igenom den här kodbasen. Och om så är fallet kommer du inte att kunna fokusera på kärnmaterialet i denna handledning.

De primära ämnen som vi syftar till att granska har således ingenting att göra med objektorienterad programmering utan förstå hur man internationaliserar och i slutändan lokaliserar ett WordPress-projekt.

Slutsats

Vid denna tidpunkt har vi ett funktionellt plugin som kan hämtas, installeras och köras inom en WordPress-installation. Även om det är internationaliserat, har vi inga lokaliseringsfiler att visa på vilket sätt processen fungerar. Du kan hämta en kopia av pluginet från sidans sidor på denna sida.

I uppföljningsövningen kommer vi att titta på hur vi kan skapa våra lokaliseringsfiler och simulera ett annat språk för att testa våra översättningar, och vi tittar också på verktyg som är tillgängliga för oss att använda.

Medan du väntar på nästa avbetalning glöm inte att se vad vi har tillgängliga på Envato Market för att hjälpa dig att bygga ut din växande uppsättning verktyg för WordPress eller till exempel kod för att studera och bli mer välbevandrad i WordPress.

Om du är intresserad av att lära dig mer om WordPress från ett utvecklingsperspektiv, notera att jag bara arbetar med WordPress och ofta skriver om det. Du kan fånga alla mina kurser och handledning på min profilsida, och du kan följa mig på min blogg och / eller Twitter på @tommcfarlin där jag pratar om mjukvaruutveckling i samband med WordPress.

Som vanligt, tveka inte att lämna några kommentarer eller frågor i kommentarfältet nedan.

referenser

  • Plugin Header
  • Text Domän
  • admin_menu
  • add_submenu_page
  • __ ()
  • esc_html_e ()
  • admin_enqueue_scripts
  • wp_enqueue_style