Selles osas keskendume sellele, kuidas tõlkida meie kohandatud Gutenbergi ploki tekste ja väärtusi. Kasutame WP-CLI-d vajalike failide genereerimiseks, et Gutenberg saaks WordPressi keele vahetamisel laadida meie tõlkeid.
Enne selle jätkamist peab teil olema installitud WP CLI (WordPressi käsurea liides). Kui teil seda pole, järgige lihtsalt WordPressi CLI käsiraamatu juhendit.
Lühidalt, kuidas Javascripti (Gutenbergi) skripte tõlkida: WordPress nõuab .mo
PHP-failide tõlkimiseks faile, kuid Javascripti jaoks nõuab WordPress .json
faili. Iga Javascripti fail vajab tõlkimiseks ühte JSON-faili. JSON peaks olema kindlas vormingus (WP CLI genereerib selle meie jaoks) koos meie tõlgitud stringidega. Vajame ühte JSON-faili iga keele kohta, millesse tahame tõlkida.
Peame esmalt lisama oma Javascripti failidesse gettexti funktsioonid (__()
jne _e()
) ja genereerima PO-faili nagu tavaliselt meie teema või pistikprogrammi jaoks. Kuna oleme oma skriptifailides olevad tekstid mähitud nt -ga __()
, peaks PO-fail neid sisaldama. Seejärel teeme tõlke nagu tavaliselt meie PO-failis. Ja lõpuks kasutame WP CLI-d, et eraldada PO-failist vajalikud stringid ja genereerida JSON-failid kõigi meie Javascript-failide jaoks.
Pidage meeles, et teie teema või pistikprogrammi .po
/ .mo
-failid ei mõjuta kunagi teie Javascripti faile – kuigi need sisaldavad meie Javascripti failidest tõlgitud stringe.
Tõlke rakendamine Javascriptis
Esimene samm on kõigi meie Javascripti faili tekstide pakkimine tõlkefunktsioonide sees. Kui olete WordPressi tõlkimisega tegelenud PHP-s, olete tõenäoliselt väga tuttav funktsioonidega __()
, _e()
jne esc_html__()
. WordPressil on pakett wp.i18n
, mis sisaldab neid funktsioone, mis töötavad täpselt nagu PHP-s.
Nagu PHP puhul, peate esitama tekstidomeeni domeeni (nimi/käepide). See võib olla mis iganes soovite, kuid jätke see lühike, sest tõenäoliselt peate seda väga sageli välja kirjutama. Oma teema jaoks olen seadistanud oma tekstidomeeni domeeniga awhitepixel
. Nii et PHP __('My string', 'awhitepixel')
-s tõlgin stringe ja Javascripti failides on see täpselt sama.
Alustame oma Javascripti faili redigeerimist. Kõigepealt peame paketist hävitama __
ja _e
funktsiooni. wp.i18n
Reacti olemuse tõttu kasutate tõenäoliselt seda __
funktsiooni enamasti või võib-olla ainult.
const { __, _e } = wp.i18n;
Ja siis tuleb kõik meie kõvakoodiga tekstid Javascripti failist üles otsida ja neid värskendada. Pidage meeles, et funktsioonid __
ja _e
nõuavad Javascripti konteksti. See tähendab, et kui tipime stringe näiteks objekti atribuutide väärtustena, kasutame seda __()
kohe, kuid väärtustena nt rekvisiitide jaoks peame kõik sees { }
mähkima, et näidata, et tegemist on Javascripti koodiga.
Näiteks meie registerBlockType
tõlketoega näeb välja selline:
registerBlockType('awp/firstblock', {
title: __('My first block', 'awhitepixel'),
category: 'common',
icon: 'smiley',
description: __('Learning in progress', 'awhitepixel'),
keywords: [__('example', 'awhitepixel'), __('test', 'awhitepixel')],
attributes: {
...
Ja mis puudutab rekvisiite, st sisse InspectorControls
:
Pakkige kõik tekstid, mille tõlkimist soovite toetada, sisse __()
ja _e()
. Kui olete seda õpetust samm-sammult järginud, ei tohiks teil esineda juhtumeid, kus peaksite kasutama _e()
. Kui olete lõpetanud, kompileerige Javascript uuesti ja me loobume Javascriptist.
Po- ja/või pot-failide seadistamine
See samm varieerub veidi sõltuvalt sellest, mida olete juba teinud ja oma teema või pistikprogrammi jaoks seadistanud. Võib-olla kirjutate oma Gutenbergi skripte uude ja tühja pistikprogrammi, mis pole PHP-tõlke jaoks seadistatud, või teema sees, millel on juba registreeritud tekstidomeen. Võimalik, et teil on valmis PO (ja MO) failid või ainult POT-fail. Annan endast parima, et katta kõik alused.
Minu teemal või pistikprogrammil on juba po(t)-fail
Kui teie projektis on juba PO- või POT-fail, on teil tõenäoliselt ka PHP funktsioon load_theme_textdomain()
või kuskil teie koodis. Veenduge, et registreeritud domeen on sama, mida olete oma Javascripti failides kasutanud.load_child_theme_textdomain()``load_plugin_textdomain()
Kõik, mida pead tegema, on laadida PO-fail selle keele jaoks, mida soovid tõlkida (või genereerida see POT-failist), näiteks PoEdit. Klõpsake nuppu „Värskenda koodist" (või muudes programmides sarnast), et programm saaks skannida kõiki projektifaile (sh meie hiljuti värskendatud Javascripti faile) ja värskendada tõlkimiseks stringide kogumit. Meie Javascripti failis olevad stringid peaksid ilmuma. Seejärel peate need lihtsalt tavaliseks tõlkima ja salvestama.
PS: Kui te ei saa klõpsata "Uuenda koodist" või faile uuesti skannida, pole PO-fail tõenäoliselt õigesti seadistatud. Otsige näpunäiteid järgmisest jaotisest.
Mul ei ole ühtegi tõlkefaili
Kui teie teema või projekt pole tõlkega seadistatud, peate WP-CLI abil looma POT-faili või looma PO-faili käsitsi.
Mul on põhjalik juhend PO-faili loomise kohta teemaõpetuses algajatele – 8. osa. Postituses kirjeldatakse, kuidas saate faili luua ja teemafailide otsimiseks õigesti seadistada ning otsitavaid märksõnu (__
, _e
, jne).
Kui soovite pigem POT-faili luua, võite kasutada WP-CLI-s käsku wp i18n make-pot ja seejärel luua sellest PO-fail, kasutades nt PoEdit. Pidage meeles, et iga kord, kui värskendate oma koodi stringe, peate POT-faili (ja seejärel PO-faili) uuesti looma.
Lõpptulemus
Lõppkokkuvõttes vajate PO-faili, mis on leidnud teie Javascripti stringid, kus need on tõlgitud. Soovitan paigutada tõlkefailid oma teemas või pistikprogrammis eraldi kausta. Kui hakkame JSON-faile genereerima, saame tõlkimiseks üsna palju faile ja on tore neid kõiki koos oma kaustas hoida.
Võrdluspunktina paigutan kõik tõlkefailid oma theme/assets/lang/
. Lisasin oma teemale norrakeelse tõlke nimega nb_NO.po
, mis sisaldab tõlgitud stringe meie kohandatud ploki Javascripti failist.
JSON-failide genereerimine po-failist
Järgmine samm on WP-CLI kasutamine meie po-failist JSON-failide genereerimiseks. Selleks kasutame käsku wp i18n make-json.
Pidage meeles, et vaikimisi eemaldab see käsk teie PO-failist tõlgitud stringid, mida kasutatakse JSON-faili genereerimiseks. See võib teema või pistikprogrammi arendamise ajal olla tülikas. Sest kui lisate uusi või kohandate stringe, peate failid uuesti skannima ja kõik stringid uuesti (ja uuesti ja uuesti) tõlkima. Õnneks on selle vältimiseks käsul lipp.
Alustame! Liikuge terminalis oma projekti keelekataloogi. Käivitage järgmine käsk ja vaadake oma po-faili (nagu mainitud, on mul nb_NO.po
fail valmis).
wp i18n make-json nb_NO.po --no-purge
Kui teil pole probleeme tõlgitud stringide eemaldamisega PO-failist (näiteks kui teete oma lõplikku ehitust), võite --no-purge
lipu vahele jätta.
Terminal peaks küsima "Edu" ja teatama, mitu JSON-faili loodi. Kui näete, et see genereeris kaks JSON-faili, on see sellepärast, et see on lugenud nii meie lähtekoodi Javascripti faili kui ka ehitusfaili ning loonud kummagi jaoks ühe. Kui teie projektis on rohkem Javascripti faile, saate lõpuks veelgi rohkem JSON-faile.
Selle kirjutamise seisuga (WordPress v 5.3.2 ja WP-CLI versioon 2.4.0) genereeritakse JSON-failid keelekoodi ja failinimedena räsi – krüptilise stringiga. Peame leidma õige ja ümber nimetama.
JSON-faili ümbernimetamine ja PHP-sse laadimine
Teie keelekaust näeb tõenäoliselt välja umbes selline:
Pidage meeles, et käsk on loonud ühe JSON-faili iga Javascripti faili kohta – ja kuna meil on kohandatud ploki jaoks tegelikult kaks faili (allikas ja järg), genereeris see kaks faili. Kui teie Javascripti kood on jagatud mitmeks failiks, saavad mõlemad kaks oma JSON-faili.
Kui teil on ainult kaks JSON-faili (kuna muid Javascripti faile ei leitud), saate ühe neist kohe kustutada. Kui teil on rohkem kui kaks, peate avama JSON-failid ja nägema, millise faili jaoks need on mõeldud. JSON-failid sisaldavad atribuuti " source
", mis ütleb teile, millise Javascripti faili jaoks see JSON-fail on mõeldud. Kasutage seda, et välja selgitada, millist JSON-faili säilitada. Soovitan leida lõplik ehitusfail (erinevalt dev-failidest), kuna see peaks sisaldama kõigi failide kõiki stringe.
Kui olete õige leidnud, peame selle ümber nimetama. Peame selle ümber nimetama, et järgida järgmist mustrit:
[textdomain]-[language code]-[script handle].json
Kasutage tekstidomeeni, mida olete kõikjal kasutanud (nt __('My string', 'awhitepixel')
), lisage sidekriips ja keelekood. Seejärel lisage sidekriips ja skripti käepide, mida kasutasite oma Gutenbergi Javascripti faili (wp_register_script()
) registreerimiseks. Viitena on minu tekstidomeen awhitepixel
, minu keelekood nb_NO
ja Gutenbergi skripti käepide on awp-myfirstblock-js
. Nii et ma nimetan JSON-faili ümber järgmiselt:
awhitepixel-nb_NO-awp-myfirstblock-js.json
Paluge WordPressil laadida meie JSON
Nüüd jääb alles viimane samm – käskida WordPressil laadida meie JSON-fail. Peame kasutama funktsiooni [wp_set_script_translations](https://developer.wordpress.org/reference/functions/wp_set_script_translations/)()
. See on üsna uus WordPressi funktsioon, nii et soovitan selle pakkida function_exists()
. See aktsepteerib kolme parameetrit; meie ploki skripti käepide, tekstidomeen ja tee meie tõlkekausta (märkus: tee, mitte URL).
Meie funktsiooni sees, mis on ühendatud funktsiooniga init
, kus registreerisime oma plokiskripti ja kõne, register_block_type
saame kutsuda ka seda uut funktsiooni JSON-i tõlkefaili laadimiseks. PS: Pidage meeles, et konks enqueue_block_assets
ei tööta tõlgete registreerimisel.
add_action('init', function() {
wp_register_script('awp-myfirstblock-js', ....);
register_block_type('awp/firstblock', ....
if (function_exists('wp_set_script_translations')) {
wp_set_script_translations('awp-myfirstblock-js', 'awhitepixel', get_template_directory(). '/assets/lang');
}
});
Ja see on kõik! Teie blokk tuleks nüüd tõlkida. Lülitage WordPressi keel keelele, millesse tõlkisite, ja kontrollige seda ise. Kui lülitan oma WordPressi keele norra keeleks ja lisan oma ploki, tõlgitakse nimi ja kõik selles sisalduv: