Internasjonalisering av WordPress-prosjekter Oppdateringer med WordPress 4.6

Gjennom hele denne serien har vi dekket nøyaktig hva du trenger å gjøre for å internasjonalisere dine WordPress-prosjekter. Hvis du ikke har lest noen av de forrige innleggene, anbefaler jeg at du sjekker dem ut.

Selv om det har vært noen endringer i hvordan internasjonalisering og lokalisering fungerer i WordPress 4.6, betyr det ikke at de tidligere opplæringsprogrammene er irrelevante. Det betyr bare at måten du velger å distribuere pluginene dine og deres lokaliseringer, vil endre.

Og det er det vi skal dekke i denne opplæringen.

Før vi begynner

Som nevnt antar denne opplæringen at du er opptatt av alt vi har diskutert hittil i denne serien. Dette inkluderer:

  • Forstå internationalisering og hvorfor det er viktig.
  • Hvordan sette opp et utviklingsmiljø for å jobbe med prøvekoden.
  • Forstå lokalisering (og forskjellen mellom internasjonalisering).
  • Slik bruker du verktøy for å begynne å oversette dine internasjonaliserte strenger.

Hvis ingen av de ovennevnte er fornuftige, vær så snill å se serien. Hvis du føler deg trygg på at du kan forklare eller bruke hvert av punktene ovenfor, er du klar til å fortsette.

Forstå endringene

Den fine tingen om denne opplæringen er at den er mer informativ enn teoretisk (eller praktisk, for den saks skyld). Det vil si at det ikke vil være noen kode å demonstrere. Det handler bare om å formidle informasjon og sørge for at du vet hva du skal bruke og når.

Før vi kommer for dypt inn i emnet, la oss sikkerhetskopiere litt og snakke om hele internasjonaliseringsprosessen av WordPress og hvordan det fungerer med å laste inn lokaliserte filer.

Hvordan internasjonalisering og lokalisering fungerer

Begrepene internasjonalisering og lokalisering er relativt enkle å forstå, men de er også lett forvirret (da jeg først startet arbeidet mitt i WordPress, selv om jeg misbrukte vilkårene).

Internationalisering er prosessen med å utvikle plugin slik at den lett kan oversettes til andre språk.

Slik er det slik at vi forbereder alle strengene og den menneskelige lesbare teksten i pluginet som må oversettes til andre lokaliteter.

Lokalisering er da handlingen om å faktisk oversette strengene og pakke dem inn i språkpakker som deretter vil bli lastet av WordPress, avhengig av lokaliteten som er angitt i installasjonen.

For eksempel, la oss si at jeg bygger et plugin, og jeg bruker amerikansk engelsk, eller i no locale som du kanskje ser det skrevet. Da kommer du til å se all teksten jeg har skrevet på mitt språk.

Men hva skjer når noen som vil bruke pluginet vil oversette den til spansk? Først vil den ansvarlige bruke et verktøy som POEdit for å gi oversettelsene for hver av strengene. 

Da vil hun eller han lagre disse i språk katalog (eller hvilken som helst katalog er brukt). Filen skal navngis basert på lokaliteten som den er relatert til. I dette tilfellet, es_ES.

Når plugin er lastet i en installasjon av WordPress som er installert på en maskin som har es_ES locale sett som standard locale, vil lokaliseringsfilen lastes inn og erstatte alle de oversatte strengene med sine spanske ekvivalenter.

Og i lang tid, så har internasjonaliseringsprosessen jobbet. Videre, hvis du velger å distribuere plugins utenfor WordPress Plugin Repository, er dette noe du fortsatt trenger å gjøre.

Men hva med at de pluginene blir distribuert i depotet?

Just-in-Time Translations

I datavitenskap er det et konsept av JIT (eller bare-i-tid), og vi hører ofte det referert til som "just-in-time" kompilering.

I beregning er samling av bare-i-tid (JIT), også kjent som dynamisk oversettelse, kompilering gjort under utførelse av et program - ved kjøretid - i stedet for før utførelse.

I den nyeste versjonen av WordPress, som er WordPress 4.6, kan internasjonaliserte plugins som følger en bestemt protokoll, utnytte fordelene ved bare-i-tid lokalisering. Fra Make WordPress-bloggen kan disse endringene oppsummeres som følger:

Siden oversettelsesfiler vanligvis er inne i wp-innhold / språk, skanner WordPress nå den katalogen for tilgjengelige oversettelser og laster dem automatisk hvis den møter et tekstdomen for første gang.

Hva betyr dette for utviklere? Kort sagt betyr det at hvis vi distribuerer arbeidet vårt via WordPress Plugin Repository, vil WordPress først skanne biblioteket med oversettelser for å se om det finnes en eksisterende plugin og dens lokale. Hvis den oppdager en, så vil den bruke den.

Hvis det ikke oppdager en oversettelse, kan det skje en av to ting:

  1. Pluggen vil ikke bli lokalisert.
  2. Pluggen bruker lokaliseringsfilen som følger med plugin-modulen.

Det er noen forbehold for denne nye tilnærmingen, skjønt:

  1. Vi trenger ikke lenger å ringe load_plugin_textdomain () i våre WordPress 4.6-baserte plugins.
  2. Hvis du er vant til å bruke unload_textdomain (), Du må manuelt laste oversettelsene etter samtalen hvis du vil bruke dem igjen.

Selv om de er enkle, anbefaler jeg på det sterkeste å lese blogginnlegget i sin helhet for å forstå hvordan det fungerer, dets funksjonalitet, og hvordan det gjelder arbeidet du gjør dag til dag.

Generelt sett finner jeg denne funksjonen utrolig fin. Det gir oss mulighet til å distribuere plugins som allerede har oversettelser tilgjengelig, og som kan lastes inn via WordPress. 

Når det er sagt, tror jeg ikke det er en unnskyldning ikke å pakke de internasjonaliserte filene. Tross alt, hvis en språkpakke ikke er funnet, vil den likevel måtte lastes fra språk katalog. 

Og hvis det endelige målet er å ha de mest robuste, robuste pluginene som er tilgjengelige, bør vi ikke stole på noe som kanskje ikke eksisterer. I stedet la oss håpe på det beste, men planlegg det verste.

Konklusjon

Og med det har vi dekket alt vi kan om hvordan WordPress håndterer internasjonalisering og lokalisering for plugins som vil være tilgjengelige i både WordPress Plugin Repository og de du vil distribuere via dine egne kanaler.

Hvis du er interessert i å lære mer om WordPress fra et utviklingsperspektiv, merk at jeg bare jobber med WordPress og ofte skriver om det. Du kan fange alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om programvareutvikling i forbindelse med WordPress.

Som alltid, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller for eksempel kode for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Marked.

Ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under, og jeg vil sikte på å svare på hver av dem.

Beslektede ressurser

Det finnes en rekke ressurser oppført nedenfor. Vær oppmerksom på at disse kommer fra tidligere opplæringsprogrammer samt hva som er nevnt i denne opplæringen, så vel. Alt dette å si, hvis du har lest de tidligere opplæringsprogrammene, bør du være i god form. Hvis du har valgt å ikke gjøre det, så sjekk minst linkene nedenfor.

  • Plugin Header
  • Tekstdomenet
  • admin_menu
  • add_submenu_page
  • __ ()
  • esc_html_e ()
  • admin_enqueue_scripts
  • wp_enqueue_style
  • Domain Path
  • POEdit
  • plugins_loaded
  • load_plugin_textdomain
  • locale

Legg også merke til at du kan være interessert i å laste ned demo-prosjektet for å undersøke kildekoden og se hvordan den fungerer. Dette gjelder spesielt hvis du ønsker å markedsføre noe utenfor WordPress Plugin Repository.