Share
For noen år siden skrev jeg om prosessen med å internasjonalisere WordPress-baserte prosjekter. Selv om jeg tror det er noen ganger når opplæringsprogrammer ikke nødvendigvis trenger oppdatering, forfriskning eller revisjon, er det andre tider der vi alle kan dra nytte av å gjenopprette emnet.
Tross alt endres programvare fra år til år, og vi får også erfaring når vi fortsetter å jobbe med et gitt program. WordPress er ikke annerledes.
Fra denne artikkelen og fortsetter til neste sett med artikler, skal vi se på følgende:
Vi skal til og med bygge en liten, men funksjonell WordPress-plugin som vil hjelpe oss å demonstrere praktisk poengene som vi har oppført over.
Før vi kommer i gang, er det imidlertid viktig å forstå hva internasjonalisering er og hva WordPress tilbyr i veien for å gjøre det. Videre er det noen få gotchas som kan overraske deg, spesielt hvis du er en erfaren programmerer.
Med det som skissert i denne serien, la oss komme i gang med å få en god forståelse for internasjonalisering av arbeidet vårt i WordPress.
WordPress Codex er alltid et av de beste stedene å starte når du ønsker å lære mer om et gitt emne. Her er det det tilbyr i veien for internasjonalisering (som vi forkorter også som i18n bare hvis du ser det skrevet på den måten):
Internationalisering er prosessen med å utvikle plugin slik at den lett kan oversettes til andre språk.
Videre fortsetter Codex å beskrive nøyaktig hvorfor dette er viktig:
Fordi WordPress brukes over hele verden, er det en god ide å lage et WordPress-plugin slik at det enkelt kan oversettes til hvilket språk som er nødvendig. Som utvikler kan det hende du ikke har en enkel tid å gi lokaliseringer for alle brukerne dine. Du kan ikke snakke deres språk etter alle. Imidlertid kan enhver utvikler internasjonalisere et tema for å tillate andre å opprette en lokalisering uten å måtte endre kildekoden selv.
Det er fornuftig, ikke sant? WordPress har omtrent en fjerdedel av nettet, og den brukes over hele verden. Hvorfor skal det arbeidet vi leverer forbli på morsmålet vi snakker?
Dette er ikke å si at det ikke er tidspunkter der dette er greit. For eksempel, hvis du bygger en løsning for noen og deg vet at de sammen med en liten gruppe skal bruke applikasjonen, så er det fornuftig å legge det på morsmål til den nevnte klienten.
Men hvis du bygger noe for utbredt distribusjon, er det ingen tvil om at du skal internasjonalisere arbeidet ditt.
Kort sagt er internasjonalisering prosessen som gjør at arbeidet vårt kan oversettes til et annet språk.
Senere i denne artikkelen skal vi se på funksjonene i WordPress API for å sikre at våre PHP-strenger er riktig internasjonalisert. Men det er en utrolig viktig advarsel som du må huske.
Husker du når du først lærte om variabler i hvilket programmeringsspråk som helst igjen når? Det var fantastisk, ikke sant? Du kan definere en variabel en gang og deretter bruke den variabelen i stedet for strengen (eller hva som helst annen verdi) hvert annet sted i koden slik at du ikke trenger å gjenta deg selv.
Faktisk er det en del av kjernebegrepene for programmering, er det ikke?
DRY-prinsippet er oppgitt som "Hvert stykke kunnskap må ha en enkelt, entydig, autoritativ representasjon i et system."
Jeg er absolutt enig i denne definisjonen. Men når det gjelder internasjonalisering av strenger i WordPress, må vi gjøre et unntak. Du vil se hvorfor øyeblikkelig, men jeg valgte å inkludere denne delen her slik at du kan unngå en eventuell fremtidig feil. Jeg har også valgt å nevne dette slik at du ikke spør om å prøve å bruke variabler i sammenheng med internasjonalisering API i fremtidige kontaktpunkter.
Hvis du husker dette nå, vil du unngå denne hindringen senere.
På dette tidspunktet er vi klar til å se på funksjonene som WordPress gir. Vi vil ikke sette dem på jobb i denne artikkelen, men vi vil se på funksjonsnavnene, hvordan de skal brukes og hva de brukes til i en større sammenheng.
Starter i neste artikkel, begynner vi å sette dem til bruk. For nå, la oss ta en titt på hva som er tilgjengelig.
Accentsconagua
__ () er uten tvil den mest populære eller mest vanlige internasjonaliseringsfunksjonen som du finner i WordPress-arbeidet. Denne funksjonen aksepterer en enkelt streng som skal oversettes og tekstdomenet som den tilhører. Det bør aldri inkludere hva som helst bortsett fra en streng (det vil si ingen HTML, ingen JavaScript, etc.)._E () ligner på funksjonen ovenfor, men i stedet for å hente den oversatte versjonen av strengen, vil den også ekko resultatet av oversettelsen til skjermen._x (): dessverre der er ganger hvor en gitt streng vil returnere feil oversettelse. Når dette skjer, er bruk av denne funksjonen nyttig, spesielt når du angir sammenhengen mellom hvordan snoren ble oversatt. Dette vil sikre at den tilsiktede versjonen av strengen returneres._ex (), akkurat som _E () og _x () oppført ovenfor, vil sørge for at den riktige oversettelsen av strengen blir ekkoet til skjermen basert på den angitte konteksten, slik at den feilaktige versjonen ikke er valgt i løpet av kjøretiden._N () er en fin funksjon fordi det tillater WordPress å velge singelen eller flertallsversjonen av det angitte nummeret basert på hvilket som brukes. Dette betyr at vi som utviklere må gi strenge for både singelen og flertallsversjonen, slik at oversettere kan oversette den, sammen med det faktiske nummeret. Men det gjør det lettere å arbeide med internasjonaliserte tall enn uten._nx () bør på dette tidspunkt være klar over hvordan det fungerer. Det er en kombinasjon av _N () som vi bare delte og _x () som var dekket over. Dette betyr at hvis du har riktig angitt singular og flertallsform av det angitte nummeret sammen med det riktige tekstdomenet, vises oversettelsen som forventet._n_noop () bør høres litt kjent for de som er kjent med datavitenskap eller datateknikk. En NOP er kort for "ingen operasjon", og i dette tilfellet er det vant til å oversette pluralstrenger som vi ikke nødvendigvis vil bruke på et bestemt tidspunkt, men vil kanskje hente senere. Kort sagt, oversetteren kan gi oversettelsen, og vi kan velge når du skal bruke dem._nx_noop () er en kombinasjon av funksjonen ovenfor og _x () funksjonen vi har sett så mange ganger før. Dette vil tillate oss å få tilgang til en oversettelse for et bestemt tekstdomen uten å faktisk oversette dem.translate_noop_plural () leser litt annerledes enn funksjonene vi har undersøkt så langt, men implementeringen er ganske enkel: Denne funksjonen gir en oversettelse av resultatet av _n_noop () og _nx_noop (). Nøkkelen til å merke seg om denne funksjonen er at den forventer det første argumentet for å være en matrise med singular- og flertalltastene som kommer fra de nevnte funksjonene.esc_html __ () er veldig lik __ (), men det er ment for bruk i HTML-koder. Det er, det er ikke ment å oversette HTML-koder, men det er ment å gripe oversettelsen og unnslippe den for sikker bruk i sammenheng med HTML.esc_html_e () er akkurat som funksjonen over den og nesten akkurat som _E () funksjon vi så på ovenfor; Det er imidlertid ment å være vant til å gå videre og ekko resultatet av oversettelsen til skjermen.esc_html_x () burde være klart på dette punktet gitt hvor mange ganger vi har sett _x () brukes i andre funksjoner. Kort sagt, dette vil gjøre det samme som _x (), men det vil gi teksten i gettext-konteksten og vil forberede den til sikker bruk i HTML.esc_attr __ () er vant til å ta den angitte strengen og skikkelig unnslippe den slik at den kan brukes trygt som et attributt som tittel Attributt av et bilde.esc_attr_e () vil vise den oversatte teksten med en ekstra koding av noen tegn som større enn mindre enn ampersands og anførselstegn. Dette er en annen funksjon som skal brukes innenfor konteksten til et attributt til et annet element.esc_attr_x () vil ta tak i oversettelsen, unnslippe den og gi den deretter i sammenheng med et elements attributt. Hvis ingen oversettelse er gitt, vil standardstrengen som ble gitt under utviklingstiden, bli brukt.number_format_18n () er en kraftig funksjon, spesielt når du jobber med en rekke lokaliteter. Hvis du for eksempel arbeider med et nummer, og du vil gjengi "1000", vil du ikke angi en andre parameter for denne funksjonen. Men hvis du jobber med valuta eller desimaler, vil du ønske å sende "2" som det andre argumentet, slik at to digitaler vil bli vedlagt etter en desimal.date_i18n () er en annen kraftig funksjon som lar deg hente datoen i et lokalisert format basert på angitt tidsstempel. For å lære mer om denne funksjonen, parametrene, og eksempler på hvordan den brukes, vennligst se sin Codex-side.Husk i avsnittet ovenfor hvor jeg snakket om å unngå bruk av variabler? Dette er hvor det kommer til nytte. Som du uten tvil har lagt merke til, tar hver av funksjonene ovenfor to parametre:
Tekstdomenet refererer til et unikt forhold mellom WordPress-plugin- eller WordPress-temaet, WordPress og oversetteren. Til syvende og sist skal det sørge for at oversetteren kan gi en oversettelse av strengen uten å tvinge oversettelsen av en annen streng andre steder i WordPress (eller en annen tredjepartsløsning).
Til slutt, er det beste alternativet å bruke sluggen av plugin som tekstdomenet. Videre bør denne parameteren alltid være en streng, ikke en variabel. Således, uansett hvor mange ganger du ender opp med å skrive det ut, ikke lagre det i en variabel. Skriv bare tekstdomenet som den andre parameteren til funksjonen.
Dette har å gjøre med hvordan oversettelsesverktøy fungerer, og vi vil se nærmere på det i en fremtidig artikkel.
Og det er primeren på internasjonaliseringsfunksjonene. Hvis du fortsatt er litt forvirret på hvordan du skal bruke noen av disse i arbeidet ditt, ikke bekymre deg. Det er mer å dekke både når det gjelder forklaring og i form av praktiske demoer.
For eksempel berørte vi kortfattet begrepet gettext, ikke sant? Og hva med JavaScript? Videre, hva med verktøyene vi har tilgjengelig for å tillate andre å oversette våre strenger? Hvordan vet vi at de fungerer som de skal??
Alt dette kommer til å bli dekket i denne serien. Men før vi kom dit, trengte vi å begynne med det grunnleggende. Så det er det vi har gjort. I neste artikkel vil vi fortsette ved å snakke litt om gettext og noen av de tilgjengelige verktøyene.
Etter det vil vi gjøre oppmerksom på å skrive kode (inkludert JavaScript) og hvordan alt passer sammen i sammenheng med våre egne WordPress-plugins.
I mellomtiden, 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 Market.
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.
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.
