Kuinka kääntää Drupalin .po-tiedostot tekoälyllä

Useimmat ihmiset yhdistävät .po-tiedostot WordPressiin, mutta gettext-muoto on vuosikymmeniä vanhempi kuin WordPress ja se vastaa käyttöliittymien käännöksistä koko avoimen lähdekoodin maailmassa. Drupal on yksi sen suurimmista käyttäjistä. Jos ylläpidät monikielistä Drupal-sivustoa, jokainen valikon tunniste, kentän kuvaus, virheilmoitus ja moduulin merkkijono kulkee .po-tiedostojen kautta täsmälleen samalla tavalla kuin WordPressissä, vain erilaisella paikkamerkkidialektillä ja erilaisella tuontityönkululla. Ja aivan kuten WordPressissä, heti kun sivustosi sisältää enemmän kuin kourallisen merkkijonoja, näiden tiedostojen käsin kääntämisestä tulee pullonkaula.

Tämä opas kertoo, kuinka kääntää Drupalin .po-tiedostoja tekoälyllä rikkomatta niitä asioita, jotka tekevät Drupalista Drupalin. Käymme läpi Drupalin käännösjärjestelmän, mistä merkkijonot todella tulevat, WordPressistä poikkeavan paikkamerkkisyntaksin, joka on ehdottomasti säilytettävä, sekä täyden vienti-, käännös- ja uudelleentuontisilmukan, mukaan lukien drush-komennot, jotka tekevät siitä toistettavan.

Miten Drupalin käännösjärjestelmä toimii

Drupal hoitaa käyttöliittymän käännöksen ytimen locale-moduulin kautta (jota joskus kutsutaan "Interface Translationiksi" nykyaikaisessa Drupalissa). Kun se on otettu käyttöön, se hallitsee lähdemerkkijonojen ja niiden käännösten tietokantataulua kielittäin, ja se voi tuoda ja viedä näitä käännöksiä tavallisina gettext-muotoisina .po-tiedostoina.

Ylläpitäjän käyttöliittymä löytyy osoitteesta /admin/config/regional/translate. Sieltä voit etsiä kääntämättömiä merkkijonoja, muokata niitä suoraan, ja mikä tärkeintä, tuoda .po-tiedoston massalataamaan käännöksiä tai viedä nykyisen tilan .po-tiedostoon offline-muokkausta varten. Tämä vienti-/muokkaus-/tuontisykli on työnkulku, jota optimoimme.

Toisin kuin WordPressissä, jossa jokainen lisäosa ja teema toimittaa omat .po- ja .mo-tiedostonsa languages/-hakemistoon, Drupal keskittää käyttöliittymän merkkijonot tietokantaansa ja käsittelee .po-tiedostoja vaihtomuotona. Vie tiedosto, työstät sitä ja tuot sen takaisin. WordPressin vaatima .mo-tiedoston kääntövaihe käsitellään sisäisesti.

Mistä merkkijonot tulevat

Drupalin merkkijonot ovat peräisin kolmesta paikasta, ja kattavan käännöksen on katettava ne kaikki:

• Ydin sisältää tuhansia käännettäviä merkkijonoja hallintaliittymää varten, lomakkeita ja järjestelmäviestejä.
• Contrib-moduulit (Views, Webform, Commerce ja muut) rekisteröivät kukin omat merkkijononsa t()-funktion kautta.
• Teemat lisäävät mallimerkkijonoja, alueiden tunnisteita ja teema-asetusten kuvauksia.

Kun viet tiedostoja osoitteesta /admin/config/regional/translate, voit rajata viennin käännettyihin, kääntämättömiin tai kaikkiin merkkijonoihin. Uutta käännöskierrosta varten vain kääntämättömien merkkijonojen vienti tuottaa kohdennetun .po-tiedoston, jossa on tarkalleen jäljellä oleva työ.

Tämän kolmilähteisen rakenteen käytännön seuraus: käännöstyösi ei ole koskaan todella "valmis". Joka kerta kun lisäät contrib-moduulin, otat käyttöön uuden ominaisuuden tai päivität Drupalin ydintä, uusi erä kääntämättömiä msgid-merkintöjä ilmestyy locale-taulukoihin. Tämän vuoksi Drupal-tiimit käsittelevät käännöstä toistuvana prosessina yhden kerran julkaisutehtävän sijaan. Sama vienti-, käännös- ja uudelleentuontisilmukka käynnistyy jokaisessa käyttöönotossa, joka koskettaa moduuleja, ja mitä nopeampi tämä silmukka on, sitä vähemmän käännösvelkaa kertyy julkaisujen välillä.

On myös syytä huomata, että Drupal voi hakea yhteisön tuottamia käännöksiä automaattisesti localize.drupal.org-sivustolta ytimeen ja suosittuihin contrib-moduuleihin. Nämä kattavat yleiset merkkijonot, mutta ne harvoin kattavat mukautettuja moduulejasi, teemaasi tai sivustosi todellisuudessa käyttämää projektikohtaista sanamuotoa. Yhteisön käännöksen ja täysin lokalisoidun sivuston välinen kuilu on juuri se työ, jonka tekoälykierros sulkee nopeasti.

Drupalin paikkamerkit eivät ole WordPressin paikkamerkkejä

Tässä on tärkein asia ymmärtää ennen kuin lähetät minkään Drupalin .po-tiedoston tekoälykääntäjälle: Drupal ei käytä printf-tyylisiä %s- ja %1$s-paikkamerkkejä, jotka ovat yleisiä WordPressissä. Drupalin t()-funktio käyttää kolmea erillistä paikkamerkin etuliitettä, joilla kullakin on erilainen escapointikäyttäytyminen:

• @variable — arvo on HTML-escapoitu, turvallinen oletusarvo käyttäjän syöttämälle tekstille.
• %variable — arvo on escapoitu ja kääritty <em>-korostusmerkintään.
• :placeholder — käytetään URL-attribuuteissa, käy läpi URL-sanitaation.

Tyypillinen Drupalin lähdemerkkijono näyttää tältä viedyssä .po-tiedostossa:

#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""

#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""

Jos kääntäjä muuttaa @count-muotoon @cuenta, korvaa @name:n käännetyllä sanalla "nimi" tai lisää välilyönnin muuttaen @count-muodon @ count-muotoon, paikkamerkki ei enää vastaa sitä, mitä t()-kutsu välittää. Drupal tulostaa silloin kirjaimellisen tunnuksen @count sivulle todellisen numeron sijaan. Käännös näyttää valmiilta, mutta sivusto on silminnähden rikki.

Tämä on sama luokka virheistä, jotka iskevät WordPressin %s-merkkijonoihin, ja käsittelemme yleistä periaatetta syvällisemmin osoitteessa Kuinka kääntää PO-tiedostoja rikkomatta koodimuuttujia. Drupalin juju on yksinkertaisesti se, että paikkamerkkityylejä on kolme yhden sijaan, ja käännöstyökalun on tunnistettava ne kaikki.

Miksi yleiset kääntäjät epäonnistuvat tässä

Liitä kyseinen node.module-merkkijono kuluttajan konekäännöslaatikkoon ja saat usein @count:n vääristyneenä, <em>-sidotun %date:n lokalisoiduksi eri tunnukseksi, tai monikkomuotojen romahtaneen yhdeksi. Mitään näistä työkaluista ei ole rakennettu gettext-semantiikkaa ajatellen. Ne kääntävät tekstiä; ne eivät ymmärrä, että @count on sopimus sovelluskoodin kanssa.

Gettext-tietoinen käännösprosessi Syntaksilukituksella käsittelee @variable-, %variable- ja :placeholder-merkkejä muuttumattomina tunnuksina. Ne lukitaan ennen käännöstä ja palautetaan sen jälkeen, jolloin ympäröivä lause kääntyy samalla kun paikkamerkit kulkevat läpi koskemattomina. Sama lukitus kattaa WordPressin %s- ja %1$s-merkit, i18next {{name}}-merkit ja rivinsisäisen HTML:n, minkä vuoksi yksi työkalu voi palvella Drupal-, Symfony- tai Laravel-projektia yhtä helposti kuin WordPress-projektia. Drupalin monikkomuodot msgid_plural-kentän kautta säilytetään monikkomuotoina eikä tasoiteta, mikä on tärkeää, koska Drupal-kielissä voi olla yhdestä kuuteen monikkovaihtoehtoa.

On myös hienovaraisempi virhetila, joka on syytä mainita. Drupalin merkkijonoihin upotetaan usein rivinsisäisiä merkintöjä ja linkkejä käännettävän tekstin sisään, kuten Lue <a href=":url">dokumentaatio</a>, jossa :url on paikkamerkki ja <a>-tagien on säilyttävä. Kääntäjä, joka ei ymmärrä rakennetta, saattaa kääntää href-attribuutin, pudottaa sulkevan tagin tai lokalisoida paikkamerkin nimen. Kontekstitietoinen tekoäly, joka lukee koko merkkijonon yhtenä yksikkönä, yhdistettynä tunnusten lukitukseen, pitää sekä merkinnän että :url-sopimuksen ehjinä kääntäen vain ihmisen luettavissa olevan "dokumentaatio"-tekstin niiden välissä.

Vienti-, käännös- ja uudelleentuontisilmukka

Toistettavassa työnkulussa on kolme vaihetta, ja drush tekee viennistä ja tuonnista skriptattavia, joten sinun ei tarvitse klikata hallintaliittymää läpi joka kerta.

Vaihe 1: Vie .po-tiedosto

Voit viedä tiedostoja käyttöliittymästä osoitteesta /admin/config/regional/translate valitsemalla kielen ja vientialueen, tai tehdä sen komentoriviltä. Locale-moduuli mahdollistaa viennin Drupalin käännöspalvelujen kautta, ja useimmat tiimit skriptaavat sen. Tyypillinen drush-kutsu käännöksen tuonnin käynnistämiseksi (käänteinen, jota käytämme vaiheessa kolme) näyttää tältä:

# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
  --type=customized --override=all

# Rebuild caches so the new strings render immediately
drush cache:rebuild

Viennin puolella, ylläpitäjän vientilomake tuottaa .po-tiedoston; monet tiimit käärivät locale-vientipalvelun pieneen mukautettuun Drush-komentoon täydellistä automaatiota varten. Kummallakin tavalla saat tuloksena standardin gettext .po-tiedoston, joka sisältää kääntämättömät msgid-merkinnät.

Vaihe 2: Käännä tiedosto

Tämä on vaihe, jossa tekoäly korvaa tuntikausien manuaalisen muokkaamisen. Lataa viety .po-tiedosto pilvikääntäjään, valitse kohdekieli ja anna sen käsitellä. Koska suuren sivuston Drupalin .po-tiedostot ylittävät rutiininomaisesti 10 Mt, kun ydin, contrib-moduulit ja teemat yhdistetään, älykäs eräkäsittely on tässä tärkeää: tiedosto pilkotaan, käännetään ja kootaan uudelleen ilman, että sinun tarvitsee jakaa sitä käsin tai törmätä kokorajoituksiin. Tuloksena on täydellinen .po-tiedosto, jossa jokainen msgstr on täytetty ja jokainen @count-, %date- ja :url-paikkamerkki on täsmälleen siellä, mistä se alkoi.

Vaihe 3: Tuo takaisin Drupaliin

Tuo käännetty tiedosto takaisin osoitteen /admin/config/regional/translate kautta tai yllä esitetyn drush locale:import-komennon avulla, ja rakenna sitten välimuisti uudelleen. Drupal yhdistää käännökset locale-taulukoihinsa, ja merkkijonot ilmestyvät sivustolle välittömästi. Suorita silmukka uudelleen aina, kun lisäät moduulin tai päivität ydintä, sillä kumpikin tuo uusia kääntämättömiä merkkijonoja.

Yksi tuonnin yksityiskohta, joka on tärkeä: --override-lippu määrittää, korvaavatko saapuvat käännökset olemassa olevat. Käytä --override=all, kun haluat tekoälykäännetyn tiedoston olevan auktoriteettinen, tai konservatiivisempaa asetusta, jos olet käsin hienosäätänyt tiettyjä merkkijonoja Drupalin käyttöliittymässä etkä halua niitä ylikirjoitettavan. Useimmissa automatisoiduissa prosessissa .po-tiedoston käsitteleminen totuuden lähteenä ja kaiken ylikirjoittaminen pitää järjestelmän ennustettavana: versionhallinnassa oleva tiedosto on se, mitä sivusto näyttää, piste.

Monikielisillä sivustoilla, joilla on useita kohdekieliä, silmukka suoritetaan kerran kieltä kohden. Vie kääntämätön joukko, käännä se saksaksi, tuo se; vie uudelleen, käännä espanjaksi, tuo se; ja niin edelleen. Koska jokainen kieli on itsenäinen .po-tiedosto, voit suorittaa ne rinnakkain, ja pilvikääntäjä, joka käsittelee niitä samanaikaisesti, muuttaa aiemmin viikon urakoitsija-ajan yhdeksi iltapäiväksi.

Drupalin .po on yksi monista formaateista

On syytä huomata, että gettext .po ei ole ainoa tapa, jolla Drupal käsittelee käännöstä. Konfiguraatio- ja sisältöentiteettejä voidaan vaihtaa myös XLIFF-muodossa, joka on standardi, johon Translation Management Tool (TMGMT) -moduuli tukeutuu ammattimaisten käännöspalvelujen työnkuluissa. Jos Drupalin lokalisointisi tapahtuu XLIFFin kautta käyttöliittymän .po-tiedostojen sijaan, paikkamerkkien säilyttämisen periaatteet ovat identtiset, mutta tiedostorakenne eroaa, ja käsittelemme tätä polkua osoitteessa XLIFF-tiedostojen kääntäminen Drupalille, Symfonylle ja Angularille.

Käyttöliittymän käännöskerrokseen kuitenkin .po-tiedostot pysyvät työhevosena. Vienti-, tekoälykäännös-, uudelleentuontisilmukka muuttaa monipäiväisen manuaalisen työn muutaman minuutin käsittelyksi, ja niin kauan kuin käyttämäsi työkalu todella ymmärtää gettext-paikkamerkit, @variable-sopimuksesi säilyvät ehjinä ja Drupal-sivustosi pysyy toimivana kaikilla kielillä, joita toimitat.

Oletko valmis kääntämään Drupalin .po-tiedostosi rikkomatta yhtäkään @variable-muuttujaa? Kokeile SimplePoTranslatea ilmaiseksi — luottokorttia ei tarvita. Ilmainen taso käsittelee standardeja gettext .po- ja .pot-tiedostoja täydellä Syntaksilukituksella, joten Drupalin paikkamerkkisi kulkevat läpi täsmälleen odotetulla tavalla.