Hva WordPress i18n er og hvorfor det er viktig: Her er alt du trenger å vite!

For de uvitende: WordPress er kjernen i nesten 43 prosent av verdens nettsteder. I tillegg er innholdsstyringssystemet (CMS) tilgjengelig på 205 forskjellige språk. Siden plattformen er en global enhet, er lokalisering viktig. WordPress i18n-prosessen er nøkkelen til dette.

Det som er "løftet" for i18n, er at det er en måte å forberede tema- og plugin-koden din for oversettelse. Deretter kan du bruke nøyaktige oversettelser til andre språk, tilpasse dem til andre kulturer og lokaliteter, og høste fordelene.

I dette innlegget skal vi diskutere WordPress i18n i mer detalj, og vise deg hvordan du bruker det. Selv om du bør ha litt kunnskap om koding, vil vi også diskutere trinnene i detalj - sammen med hva WordPress i18n er (og gjør).

Hva i18n står for

Som et produkt av en svunnen tid lever "leet speak" i beste velgående i nettutviklingskretser. Selv om du ikke vil se mye av "l33t" og "n00b", vil du se mange numeronymer: a11y når diskusjonen handler om tilgjengelighet, for eksempel.

Faktisk er i18n et annet numeronym. Det står for "internasjonalisering", og består av den første og siste bokstaven kombinert med et tall som angir hvor mange andre bokstaver som ligger mellom dem. Du vil også finne at lokalisering har sitt eget numeronym: l10n. Det finnes også andre numeronymer, for eksempel globalisering (g11n), europeisering (e13n) og mange flere.

Her skal vi se nærmere på internasjonalisering. I den offisielle briefen fra World Wide Web Consortium (W3C) står det at dette er når design og utvikling muliggjør enkel lokalisering for brukere fra ulike kulturer, lokaliteter, språk og mer.

Det er viktig å merke seg at internasjonalisering bare er et første trinn i oversettelsesprosessen. Deretter utfører du lokaliseringen ved hjelp av en egnet oversettelsesløsning.

Grunnleggende om i18n-lokaliseringsprosessen

For selve i18n-prosessen er det en rekke trinn som WordPress-utvikleren må ta før de overleverer til oversetteren. I et nøtteskall går lokaliseringsprosessen som følger:

• Legg til en "tekstdomene"-tagg i sideoverskriftene.
• Last inn en språkfil ved hjelp av noen dedikerte WordPress-funksjoner.
• "Merk opp" tekststrenger ved hjelp av "gettext"-funksjoner (vi skal snakke om dette om et øyeblikk).
• Generer enPOT-fil(Portable Object Template) for temaet eller programtillegget ditt, og inkluder den.
• Det kan være lurt å opprette en CSS-fil (Cascading StyleSheets) for høyre-til-venstre-tale (RTL).

Oversetteren tar .pot-filen og bruker den til å utføre lokaliseringen, så den er en viktig del av prosedyren.

En kort innføring i gettext-verktøyet

For de uvitende er POT-filer et eksempel på filer du genererer ved hjelp av GNU gettext-verktøyet. Dette er teknologi og programvare fra 1980-tallet som fremdeles har stor verdi for dem som driver med i18n i dag.

Det er ikke nødvendig å vite nøyaktig hva dette er for å utføre WordPress i18n, men det er nyttig å forstå hva det gjør i generell forstand, og hva det genererer. Se på gettext som et rammeverk som hjelper WordPress med å produsere flerspråklige meldinger.

Du vil ofte se en rekke filer knyttet til gettext:

• POT-filer. Dette er malen for i18n-arbeidet ditt, og det er denne oversetteren bruker til å starte sin del av prosessen.
• Portable Object-filer (PO-filer). Det er i praksis ingen forskjell mellom POT- og PO-filer. Under oversettelsen vil PO-filen inneholde tekststrenger på både det opprinnelige og det oversatte språket.
• Maskinobjektfiler (MO-filer). MO-filer er den WordPress-kodevennlige versjonen av en PO-fil. Denne ligger i tema- eller plugin-katalogen i installasjonen din, og vil tjene oversettelsene når WordPress trenger dem.

Med alt dette i bakhodet kan du nesten begynne i18n-prosessen. Først er det lurt å forberede WordPress-nettstedet ditt på arbeidet som venter.

Før du begynner å gjennomføre WordPress i18n-prosessen

Som med alle prosjekter som gjelder WordPress-kjernefiler, bør du sørge for at installasjonen din er "ren" før du begynner. Du bør også sørge for at du kan rulle tilbake eventuelle endringer du gjør, i tilfelle det verste skulle skje og du må gjenopprette.

Derfor er det to nesten ufravikelige "forhåndstrinn" før i18n-prosessen:

• Ta full sikkerhetskopi av nettstedet ditt. Dette bør være en selvfølge, for en fullstendig sikkerhetskopi er den eneste måten å beskytte nettstedet ditt på hvis du må begynne på nytt igjen.
• Gjennomfør en plugin-revisjon. Det er lurt å ta en titt på alle programtilleggene du har på nettstedet ditt, og vurdere to spørsmål: Finnes det en oppdatering tilgjengelig, og trenger jeg programtillegget?

Når det gjelder sistnevnte, anbefaler vi at du oppdaterer de programtilleggene du ønsker å beholde, og sletter de som er overflødige.

Nok en gang kommer vi til å jobbe i WordPress-kjernefilene dine, så det er lurt å ha kunnskap om hvordan disse fungerer og hva de inneholder. Noen av konseptene vi snakker om i opplæringen vil ikke nødvendigvis ha en forklaring, selv om trinnene i seg selv vil ha det.

Når alle disse punktene er fullført, kan du begynne å jobbe med i18n-prosessen.

Slik gjennomfører du WordPress i18n-prosessen med temaer og plugins

I løpet av de neste par avsnittene viser vi deg hvordan du gjennomfører WordPress i18n med temaene og pluginene dine. Selv om hvert avsnitt kan være kodetungt og teknisk på enkelte steder, kommer vi til å forklare alt så grundig som mulig, og lenke til eventuelle ytterligere ressurser du måtte trenge.

Vi begynner med hvordan du internasjonaliserer temaene dine.

Hvordan lage et oversettelsesvennlig WordPress-tema

Det første trinnet er å oppdatere temaets topptekst slik at den inkluderer et tekstdomene og en domenebane. Kort sagt:

• Tekstdomenet hjelper WordPress med å forstå hvilke strenger som "tilhører" temaet. Dette må samsvare med temaets (og programtilleggets) slug.
• Domenebanen er mappen i temaets filer der oversettelsesfilene skal "bo". Katalogen /languages/ er det typiske standardnavnet, men du kan bruke et annet navn hvis du har behov for det.

Dette gjøres ved å legge til noen få ord i temaets header-fil:

/*
Temanavn: Mitt tilpassede tema
Forfatter: Weglot Oversett
Tekstdomene: mitt-tema
Domenesti: /språk/
*/

Deretter må du laste inn tekstdomenet ved hjelp av en "action" og en "function":

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

Denne koden må ligge i temaets functions.php-fil, og ikke på nettstedet ditt. Når du har gjort dette, kan du begynne å utføre en "strengrevisjon". Dette krever at du pakker inn alle tekststrengene i temaet ditt i oversettelsesfunksjoner. Det er to funksjoner du ofte vil bruke:

• __(). Denne inkluderer en dobbel understreking (eller "dunder") og returnerer en oversatt streng.
• _e(). Dette gir ekko (eller skriver ut) den oversatte strengen slik den presenteres.

Disse funksjonene krever to argumenter: tekststrengen og tekstdomenet. For eksempel

__()
$welcome = __( 'Hello! Welcome to the dashboard!', 'my-theme' );
_e( 'Hello again!', 'my-theme' );‍

Selv om det ikke er mulig å gå i dybden på de ulike oversettelsesfunksjonene i denne artikkelen, inneholder WordPress Theme Developers' Handbook nesten all den informasjonen du trenger for å gjøre jobben.

Nå kan du opprette en POT-fil. Det finnes mange løsninger for å gjøre dette, men WordPress anbefaler Poedit - en gratis løsning med åpen kildekode.

Når du har lastet ned og installert Poedit, går du til Fil > Ny i verktøylinjen:

Deretter oppretter du en ny katalog. Du kan klikke på koblingen Utdrag fra kilder i hovedskjermbildet:

Deretter fyller du ut feltene for prosjektnavn, språkteam og hovedspråk i fanen Oversettelsesegenskaper:

Hvis filen er ny, bør du lagre den her (filnavnet bør være det samme som sluggen til temaet ditt). Deretter velger du fanen Sources Paths og finner mappen /languages/ på datamaskinen din:

Den siste fanen Kilder nøkkelord inneholder en liste over oversettelsesfunksjonene du har brukt i temaet ditt:

Det kan være lurt å legge dem til her, selv om det kan være vanskelig å finne de riktige nøkkelordene. Som en begynnelse kan du bruke følgende liste:

__
_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‍ esc_attr_x

Når du klikker for å bekrefte, lagrer du endringene og sjekker de nye filene dine: Du vil se MO- og PO-filer på datamaskinen. Hvis du dupliserer PO-filen, kan du legge til POT-utvidelsen, og herfra kan du gå videre til lokalisering.

Slik lager du en oversettelsesklar WordPress-plugin

Den første oppgaven din her ligner på et tema: Først må du oppdatere plugin-modulens tekstdomene- og domenesti-felt i toppteksten:

/*
Plugin-navn: Min tilpassede plugin
Plugin-URI: https:// weglot .com
Beskrivelse: En tilpasset plugin for å vise frem oversettelse og i18n.
Forfatter: Weglot Oversett
Versjon: 1.0
Forfatter-URI: https:// weglot .com
Tekstdomene: min-plugin
Domenesti: /språk/
*/

Vi anbefaler at du oppretter en /languages/-mappe for domenestien og angir denne som domenestien. Derfra kan du laste inn tekstdomenet for plugin-modulen, men denne gangen kan du legge til følgende funksjon i koden din, i stedet for gjennom functions.php:

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

Dette gir imidlertid bare WordPress beskjed om at det finnes en oversettelsesfil tilgjengelig. For å laste den inn, må du pakke funksjonen inn i en handling:

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

Mye av strengrevisjonen vil være lik tema i18n. Det siste trinnet er å generere en POT-fil ved å bruke samme prosess som tidligere; den genererte filen vil ende opp i den nåværende arbeidskatalogen

Begrensningene ved WordPress i18n

Nå forstår du nok hvor fantastisk WordPress i18n kan være. Det er flott hvis du utvikler temaer eller programtillegg og ønsker å gjøre dem klare til å oversettes. Men som med alle gode ting, finnes det også noen ulemper.

Hvis en plugin for eksempel inneholder brukergenerert innhold, vil dette ikke være en del av i18n-oversettelsen.

i18n-prosessen vil muliggjøre oversettelser for statiske elementer du koder, for eksempel knapptekst. Men hvis brukeren ønsker å skrive inn en spesifikk frase for et felt, opprette unike etiketter og andre elementer på klientsiden, vil du ikke kunne ta hensyn til dette. Det kan du faktisk, men det er en kompleks oppgave som ligger utenfor rammen av et innlegg som dette.

Hvis du ikke er en utvikler, vil i18n heller ikke hjelpe deg med å oversette nettstedet ditt. Til dette trenger du en plugin, og det kan være lurt å hoppe videre til neste avsnitt for å finne et passende alternativ.

Det er også verdt å merke seg at selv om oversettelsespluginer kan hjelpe på mange måter, trenger et nettsted i gjennomsnitt fem pluginer for å være fullstendig flerspråklig. I motsetning til dette er en løsning som Weglot rask å bruke, i stand til å oppdage alle de oversettbare delene av et nettsted, og er kompatibel med nesten alle temaer og pluginer. Dette gjelder uavhengig av om disse temaene og pluginene er klare til å oversettes.

Dessuten, Weglot bruker temaet, plugin-modulen og hovedinnholdselementene fra HTML-forsiden og gjør disse oversettbare. Som sådan finnes det ingen .pot- og .po-filer, og gettext-metoden er heller ikke nødvendig.

Hvordan Weglot Støtter WordPress i18n

I tekniske termer skal vi nå diskutere lokaliseringen av innholdet ditt - den direkte oversettelsesprosessen.

En god oversettelsesstrategi er ikke enkel. Det er hardt arbeid og krever mye planlegging for å sikre at innholdet ditt når ut til ulike kulturer, steder og språk på riktig måte. Dette handler ikke bare om den oversatte teksten i brødteksten. Du må også ta hensyn til alt det følgende:

• De pene permalenkene du bruker.
• Metadata for innlegg og sider.
• Medier, for eksempel bilder, videoer, GIF-er, ikoner og mer - inkludert tilhørende metadata.

Hvis du bruker netthandel , er det også en rekke ting du bør vurdere her. For eksempel bør du sørge for at betalingsskjermen din tilbyr en fullstendig oversettelse av alle elementer – spesielt valuta- og skattefeltene dine:

Fraktinformasjon er dessuten et viktig aspekt som må oversettes i sin helhet og med høy kvalitet. Du vil at kundene ikke skal ha noen unnskyldning for å klikke på Kjøp-knappen, uansett hvilket språk du bruker.

Weglot utfører mye av det tunge arbeidet for deg. Det er en verdifull alliert for WordPress i18n-arbeidet ditt fordi det oppdager alle aspekter av nettstedet ditt som du kan oversette. Derfra vil det utføre et første lag med maskinoversettelse for deg:

Dette kan være nok for dine behov, men Weglot kan hjelpe deg et skritt videre. Du kan hente inn profesjonelle oversettelser, redigere eksisterende oversettelser og mye mer. Dette gir deg all fleksibiliteten du trenger for å gjennomføre en fullstendig lokalisering av nettstedet ditt.

Konklusjon

WordPress er tilgjengelig nesten overalt i verden. Internasjonaliserte temaer og plugins vil derfor være til hjelp når de skal oversettes til andre språk. WordPress i18n er en viktig brikke i hjulet for utviklere som jobber med plattformen.

Hvis du kan internasjonalisere temaet ditt slik at brukerne kan lage oversettelser uten å endre kildekoden, har du et godt utgangspunkt. Men bare fordi du bruker i18n-konsepter, betyr det ikke at temaet eller programtillegget ditt er oversatt.

For å utføre dette trinnet, bør du bruke en løsning som Weglot . Den er kompatibel med mange forskjellige plattformer og teknologier , og fungerer fantastisk med WordPress . Når du har fullført i18n-delen av arbeidsflyten din, kan du gå til Weglot å generere nøyaktige og enkle oversettelser å implementere på nesten alle språk.

For å finne ut av det selv, Weglot tilbyr en 10-dagers gratis prøveperiode uten kjøpsforpliktelse.