Cum să construiți o aplicație multilingvă: o demonstrație cu PHP și Gettext

Indiferent dacă construiți un site web sau o aplicație web cu drepturi depline, pentru a o face accesibilă unui public mai larg necesită adesea să fie disponibilă în diferite limbi și localități.

Diferențele fundamentale dintre majoritatea limbilor umane fac ca acest lucru să fie ceva mai ușor. Diferențele dintre regulile gramaticale, nuanțele de limbă, formatele de date și multe altele se combină pentru a face din localizare o provocare unică și formidabilă.

Luați în considerare acest exemplu simplu.

Regulile de pluralizare în limba engleză sunt destul de simple: puteți avea o formă singulară a unui cuvânt sau o formă de plural a unui cuvânt.

În alte limbi, totuși, cum ar fi limbile slave, există două forme de plural în plus față de cea singular. Puteți găsi chiar și limbi cu un total de patru, cinci sau șase forme de plural, cum ar fi în slovenă, irlandeză sau arabă.

Modul în care este organizat codul și modul în care sunt proiectate componentele și interfața dvs. joacă un rol important în determinarea cât de ușor vă puteți localiza aplicația.

Internaționalizarea (i18n) a bazei de cod vă ajută să vă asigurați că acesta poate fi adaptat la diferite limbi sau regiuni cu relativă ușurință. Internaționalizarea se face, de obicei, o singură dată, de preferință la începutul proiectului, pentru a evita necesitatea unor schimbări uriașe în codul sursă pe drum.

Odată ce baza de cod a fost internaționalizată, localizarea (l10n) devine o chestiune de traducere a conținutului aplicației dvs. într-o anumită limbă/localizare.

Localizarea trebuie efectuată de fiecare dată când o nouă limbă sau regiune trebuie să fie acceptată. De asemenea, ori de câte ori o parte a interfeței (conținând text) este actualizată, devine disponibil conținut nou - care apoi trebuie să fie localizat (adică, tradus) în toate localurile acceptate.

În acest articol, vom învăța cum să internaționalizăm și să localizăm software-ul scris în PHP. Vom parcurge diferitele opțiuni de implementare și diferitele instrumente care ne sunt disponibile pentru a ușura procesul.

Instrumente pentru internaționalizare

Cel mai simplu mod de a internaționaliza software-ul PHP este prin utilizarea fișierelor matrice. Matricele vor fi populate cu șiruri traduse, care pot fi apoi căutate din șabloane:

 <h1><?=$TRANS['title_about_page']?></h1>

Aceasta este, totuși, o modalitate cu greu recomandată pentru proiecte serioase, deoarece cu siguranță va pune probleme de întreținere pe viitor. Unele probleme ar putea apărea chiar la început, cum ar fi lipsa suportului pentru interpolarea variabilelor sau pluralizarea substantivelor și așa mai departe.

Unul dintre cele mai clasice instrumente (deseori luate ca referință pentru i18n și l10n) este un instrument Unix numit Gettext.

Deși datează din 1995, este încă un instrument cuprinzător pentru traducerea software-ului, care este, de asemenea, ușor de utilizat. Deși este destul de ușor să începeți, are totuși instrumente puternice de asistență.

Gettext este ceea ce vom folosi în această postare. Vom prezenta o aplicație GUI grozavă care poate fi utilizată pentru a actualiza cu ușurință fișierele sursă l10n, evitând astfel nevoia de a trata linia de comandă.

Biblioteci pentru a ușura lucrurile

Există cadre web și biblioteci PHP majore care acceptă Gettext și alte implementări ale i18n. Unele sunt mai ușor de instalat decât altele sau prezintă caracteristici suplimentare sau acceptă diferite formate de fișiere i18n. Deși în acest document, ne concentrăm pe instrumentele furnizate cu nucleul PHP, iată o listă cu altele care merită menționate:

• oscarotero/Gettext: suport pentru Gettext cu o interfață orientată pe obiecte; include funcții de ajutor îmbunătățite, extractoare puternice pentru mai multe formate de fișiere (unele dintre ele nu sunt acceptate nativ de comanda gettext ). Poate exporta și în formate dincolo de fișierele .mo/.po, ceea ce poate fi util dacă trebuie să integrați fișierele de traducere în alte părți ale sistemului, cum ar fi o interfață JavaScript.

• symfony/traducere: Acceptă o mulțime de formate diferite, dar recomandă utilizarea XLIFF-urilor detaliate. Nu include funcții de ajutor sau un extractor încorporat, dar acceptă substituenți folosind strtr() intern.

• zend/i18n: acceptă fișiere matrice și INI sau formate Gettext. Implementează un strat de cache pentru a evita necesitatea de a citi sistemul de fișiere de fiecare dată. Include, de asemenea, ajutoare pentru vizualizare și filtre de intrare și validatori care țin cont de locație. Cu toate acestea, nu are extractor de mesaje.

Alte cadre includ, de asemenea, module i18n, dar acestea nu sunt disponibile în afara bazelor lor de cod:

• Laravel: acceptă fișiere matrice de bază; nu are extractor automat, dar include un ajutor @lang pentru fișierele șablon.

• Yii: acceptă matrice, Gettext și traducere bazată pe baze de date și include un extractor de mesaje. Susținut de extensia Intl , disponibilă începând cu PHP 5.3 și bazat pe proiectul ICU. Acest lucru îi permite lui Yii să execute înlocuiri puternice, cum ar fi scrierea numerelor, formatarea datelor, orelor, intervalelor, monedei și ordinale.

Dacă decideți să alegeți una dintre bibliotecile care nu oferă extractoare, poate doriți să utilizați formatele Gettext, astfel încât să puteți utiliza lanțul de instrumente Gettext original (inclusiv Poedit), așa cum este descris în restul capitolului.

Instalarea Gettext

Poate fi necesar să instalați Gettext și biblioteca PHP aferentă utilizând managerul de pachete, cum ar fi apt-get sau yum. După ce este instalat, activați-l adăugând extension=gettext.so (Linux/Unix) sau extension=php_gettext.dll (Windows) la fișierul dvs. php.ini .

Aici vom folosi și Poedit pentru a crea fișiere de traducere. Probabil îl veți găsi în managerul de pachete al sistemului dvs.; este disponibil pentru Unix, Mac și Windows și poate fi descărcat gratuit și de pe site-ul său web.

Tipuri de fișiere Gettext

Există trei tipuri de fișiere cu care vă ocupați de obicei în timp ce lucrați cu Gettext.

Principalele sunt fișierele PO (Obiect portabil) și MO (Obiect mașină), primul fiind o listă de „obiecte traduse” lizibile, iar al doilea fiind binarul corespunzător (pentru a fi interpretat de către Gettext când faceți localizarea). Există, de asemenea, un fișier POT (Șablon PO), care conține pur și simplu toate cheile existente din fișierele sursă și poate fi folosit ca ghid pentru a genera și actualiza toate fișierele PO.

Fișierele șablon nu sunt obligatorii; în funcție de instrumentul pe care îl utilizați pentru a face l10n, veți fi bine doar cu fișiere PO/MO. Veți avea o pereche de fișiere PO/MO per limbă și regiune, dar doar un POT per domeniu.

Separarea domeniilor

Există unele cazuri, în proiecte mari, în care ar putea fi necesar să separați traducerile atunci când aceleași cuvinte au un sens diferit în contexte diferite.

În aceste cazuri, va trebui să le împărțiți în „domenii” diferite, care sunt, în principiu, numite grupuri de fișiere POT/PO/MO, unde numele fișierului este domeniul de traducere menționat.

Proiectele mici și mijlocii de obicei, pentru simplitate, folosesc un singur domeniu; numele său este arbitrar, dar vom folosi „principal” pentru mostrele noastre de cod.

În proiectele Symfony, de exemplu, domeniile sunt folosite pentru a separa traducerea pentru mesajele de validare.

Cod local

Un local este pur și simplu un cod care identifică o versiune a unei limbi. Este definit conform specificațiilor ISO 639-1 și ISO 3166-1 alpha-2: două litere minuscule pentru limbă, urmate opțional de un caracter de subliniere și două litere mari de identificare a țării sau a codului regional.

Pentru limbile rare, sunt folosite trei litere.

Pentru unii vorbitori, partea de țară poate părea redundantă. De fapt, unele limbi au dialecte în diferite țări, cum ar fi germană austriacă (de_AT) sau portugheză braziliană (pt_BR). A doua parte este folosită pentru a face distincția între acele dialecte - atunci când nu este prezentă, este luată ca o versiune „generică” sau „hibridă” a limbii.

Structura directorului

Pentru a folosi Gettext, va trebui să aderăm la o structură specifică de foldere.

În primul rând, va trebui să selectați o rădăcină arbitrară pentru fișierele dvs. l10n din depozitul sursă. În interiorul acestuia, veți avea un folder pentru fiecare localizare necesară și un folder fix „LC_MESSAGES” care va conține toate perechile PO/MO.

Forme de plural

După cum am spus în introducere, diferitele limbi pot avea reguli diferite de pluralizare. Cu toate acestea, Gettext ne scutește de această problemă.

Când creați un fișier .po nou, va trebui să declarați regulile de pluralizare pentru limba respectivă, iar piesele traduse care sunt sensibile la plural vor avea o formă diferită pentru fiecare dintre aceste reguli.

Când apelați Gettext în cod, va trebui să specificați un număr legat de propoziție (de exemplu, pentru expresia „Aveți n mesaje.”, va trebui să specificați valoarea lui n) și va găsi forma corectă. de utilizat - chiar și folosind înlocuirea șirurilor de caractere dacă este necesar.

Regulile plurale sunt compuse din numărul de reguli necesare cu un test boolean pentru fiecare regulă (testul pentru cel mult o regulă poate fi omis). De exemplu:

• japoneză: nplurals=1; plural=0; nplurals=1; plural=0; - o singură regulă: nu există forme de plural

• engleză: nplurals=2; plural=(n != 1); nplurals=2; plural=(n != 1); - două reguli: folosiți forma pluralului numai când n nu este 1, în caz contrar folosiți forma singularului.

• portugheză braziliană: nplurals=2; plural=(n > 1); nplurals=2; plural=(n > 1); - două reguli, folosiți forma de plural numai când n este mai mare decât 1, în caz contrar folosiți forma singulară.

Pentru o explicație mai profundă, există un tutorial informativ LingoHub disponibil online.

Gettext va determina ce regulă să folosească pe baza numărului furnizat și va folosi versiunea corectă localizată a șirului. Pentru șirurile în care pluralizarea trebuie gestionată, va trebui să includeți în fișierul .po o propoziție diferită pentru fiecare regulă de plural definită.

Implementarea eșantionului

După toată această teorie, să fim puțin practici. Iată un extras dintr-un fișier .po (nu vă faceți încă prea multe griji cu privire la sintaxă, ci doar obțineți o idee a conținutului general):

 msgid "" msgstr "" "Language: pt_BR\n" "Content-Type: text/plain; charset=UTF-8\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" msgid "We're now translating some strings" msgstr "Nos estamos traduzindo algumas strings agora" msgid "Hello %1$s! Your last visit was on %2$s" msgstr "Ola %1$s! Sua ultima visita foi em %2$s" msgid "Only one unread message" msgid_plural "%d unread messages" msgstr[0] "So uma mensagem nao lida" msgstr[1] "%d mensagens nao lidas"

Prima secțiune funcționează ca un antet, având msgid și msgstr goale.

Descrie codificarea fișierului, formele de plural și alte câteva lucruri. A doua secțiune traduce un șir simplu din engleză în portugheză braziliană, iar a treia face același lucru, dar folosește înlocuirea șirurilor din sprintf , permițând traducerii să conțină numele de utilizator și data vizitei.

Ultima secțiune este un eșantion de forme de pluralizare, afișând versiunea la singular și la plural ca msgid în engleză și traducerile corespunzătoare ca msgstr 0 și 1 (urmând numărul dat de regula pluralului).

Acolo se folosește și înlocuirea șirurilor, astfel încât numărul poate fi văzut direct în propoziție, folosind %d . Formele de plural au întotdeauna două msgid (singular și plural), așa că este recomandat să nu folosiți un limbaj complex ca sursă de traducere.

Chei de localizare

După cum probabil ați observat, folosim propoziția în limba engleză ca ID sursă. Acest msgid este același folosit în toate fișierele dvs. .po, ceea ce înseamnă că alte limbi vor avea același format și aceleași câmpuri msgid , dar liniile msgstr traduse.

Vorbind despre cheile de traducere, există două abordări „filosofice” standard aici:

1. msgid ca o propoziție reală

Principalele avantaje ale acestei abordări sunt:

• Dacă există părți ale software-ului netraduse într-o anumită limbă, cheia afișată va păstra în continuare un anumit sens. De exemplu, dacă știți cum să traduceți din engleză în spaniolă, dar aveți nevoie de ajutor pentru a traduce în franceză, ați putea publica noua pagină cu propoziții în franceză lipsă, iar părți ale site-ului web vor fi afișate în schimb în engleză.

• Este mult mai ușor pentru traducător să înțeleagă ce se întâmplă și să facă o traducere corectă bazată pe msgid .

• Vă oferă l10n „gratuit” pentru o singură limbă - cea sursă.

Pe de altă parte, dezavantajul principal este că, dacă trebuie să modificați textul real, trebuie să înlocuiți același msgid în mai multe fișiere de limbă.

2. msgid ca o cheie unică, structurată

Aceasta ar descrie rolul propoziției în aplicație într-un mod structurat, inclusiv șablonul sau partea în care se află șirul în loc de conținutul său.

Aceasta este o modalitate excelentă de a avea codul organizat, separând conținutul textului de logica șablonului. Totuși, asta ar putea prezenta probleme traducătorului, care ar pierde contextul.

Un fișier în limba sursă ar fi necesar ca bază pentru alte traduceri. De exemplu, în mod ideal, dezvoltatorul ar avea un fișier „en.po”, pe care traducătorii l-ar citi pentru a înțelege ce să scrie în „fr.po”.

Traducerile lipsă ar afișa pe ecran chei fără sens („top_menu.welcome” în loc de „Bună ziua, utilizator!” pe pagina franceză netradusă menționată).

Este bine, deoarece ar forța traducerea să fie completă înainte de publicare - dar rău, deoarece problemele de traducere ar fi cu adevărat îngrozitoare în interfață. Unele biblioteci, totuși, includ o opțiune de a specifica o anumită limbă ca „de rezervă”, având un comportament similar cu cealaltă abordare.

Manualul Gettext favorizează prima abordare deoarece, în general, este mai ușor pentru traducători și utilizatori în caz de probleme. Aceasta este abordarea pe care o vom folosi și aici.

Trebuie remarcat, totuși, că documentația Symfony favorizează traducerea bazată pe cuvinte cheie, pentru a permite modificări independente ale tuturor traducerilor fără a afecta și șabloanele.

Utilizare zilnică

Într-o aplicație comună, ați folosi unele funcții Gettext în timp ce scrieți text static în paginile dvs.

Aceste propoziții ar apărea apoi în fișiere .po, vor fi traduse, compilate în fișiere .mo și apoi folosite de Gettext atunci când redau interfața reală. Având în vedere acest lucru, să legăm ceea ce am discutat până acum într-un exemplu pas cu pas:

1. Un exemplu de fișier șablon, inclusiv câteva apeluri gettext diferite

 <?php include 'i18n_setup.php' ?> <div> <h1><?=sprintf(gettext('Welcome, %s!'), $name)?></h1> <!-- code indented this way only for legibility → <?php if ($unread): ?> <h2> <?=sprintf( ngettext('Only one unread message', '%d unread messages', $unread), $unread )?> </h2> <?php endif ?> </div> <h1><?=gettext('Introduction')?></h1> <p><?=gettext('We\'re now translating some strings')?></p>

• gettext() pur și simplu traduce un msgid în msgstr -ul corespunzător pentru o limbă dată. Există, de asemenea, funcția scurtă _() care funcționează în același mod

• ngettext() face același lucru, dar cu reguli de plural

• Există, de asemenea, dgettext() și dngettext() , care vă permit să suprascrieți domeniul pentru un singur apel (mai multe despre configurarea domeniului în exemplul următor)

2. Un exemplu de fișier de configurare (i18n_setup.php așa cum este folosit mai sus), selectând localul corect și configurând Gettext

Folosirea Gettext implică un pic de cod standard, dar este vorba în principal despre configurarea directorului locale și alegerea parametrilor corespunzători (un local și un domeniu).

 <?php /** * Verifies if the given $locale is supported in the project * @param string $locale * @return bool */ function valid($locale) { return in_array($locale, ['en_US', 'en', 'pt_BR', 'pt', 'es_ES', 'es'); } //setting the source/default locale, for informational purposes $lang = 'en_US'; if (isset($_GET['lang']) && valid($_GET['lang'])) { // the locale can be changed through the query-string $lang = $_GET['lang']; //you should sanitize this! setcookie('lang', $lang); //it's stored in a cookie so it can be reused } elseif (isset($_COOKIE['lang']) && valid($_COOKIE['lang'])) { // if the cookie is present instead, let's just keep it $lang = $_COOKIE['lang']; //you should sanitize this! } elseif (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) { // default: look for the languages the browser says the user accepts $langs = explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']); array_walk($langs, function (&$lang) { $lang = strtr(strtok($lang, ';'), ['-' => '_']); }); foreach ($langs as $browser_lang) { if (valid($browser_lang)) { $lang = $browser_lang; break; } } } // here we define the global system locale given the found language putenv("LANG=$lang"); // this might be useful for date functions (LC_TIME) or money formatting (LC_MONETARY), for instance setlocale(LC_ALL, $lang); // this will make Gettext look for ../locales/<lang>/LC_MESSAGES/main.mo bindtextdomain('main', '../locales'); // indicates in what encoding the file should be read bind_textdomain_codeset('main', 'UTF-8'); // if your application has additional domains, as cited before, you should bind them here as well bindtextdomain('forum', '../locales'); bind_textdomain_codeset('forum', 'UTF-8'); // here we indicate the default domain the gettext() calls will respond to textdomain('main'); // this would look for the string in forum.mo instead of main.mo // echo dgettext('forum', 'Welcome back!'); ?>

3. Pregătirea traducerii pentru prima rulare

Unul dintre marile avantaje pe care le are Gettext față de pachetele personalizate de cadru i18n este formatul său extins și puternic de fișier.

Poate că vă gândiți „O, omule, este destul de greu de înțeles și editat manual, o simplă matrice ar fi mai ușor!” Nu vă înșelați, aplicații precum Poedit sunt aici pentru a vă ajuta - foarte multe. Puteți obține programul de pe site-ul lor, este gratuit și disponibil pentru toate platformele. Este un instrument destul de ușor de obișnuit și unul foarte puternic în același timp - folosind toate funcțiile pe care le are Gettext. Vom lucra aici cu cea mai recentă versiune, Poedit 1.8.

La prima rulare, ar trebui să selectați „Fișier > Nou...” din meniu. Vi se va cere limba; selectați/filtrați limba în care doriți să traduceți sau utilizați formatul menționat anterior, cum ar fi en_US sau pt_BR .

Acum, salvați fișierul - folosind și structura de directoare pe care am menționat-o. Apoi ar trebui să faceți clic pe „Extragere din surse”, iar aici veți configura diverse setări pentru sarcinile de extragere și traducere. Pe toate le veți putea găsi mai târziu prin „Catalog > Proprietăți”:

• Căi sursă: includeți toate folderele din proiect în care sunt numite gettext() (și frații) - acesta este de obicei folderul(ele) de șabloane/vizualizări. Aceasta este singura setare obligatorie.

• Proprietăți de traducere:

  • Numele și versiunea proiectului, adresa de e-mail a echipei și a echipei: informații utile care se află în antetul fișierului .po.
  • Forme de plural: Acestea sunt regulile pe care le-am menționat anterior. Puteți lăsa opțiunea implicită de cele mai multe ori, deoarece Poedit include deja o bază de date la îndemână cu reguli de plural pentru multe limbi.
  • Seturi de caractere: UTF-8, de preferință.
  • Setul de caractere cod sursă: Setul de caractere folosit de baza de cod - probabil și UTF-8, nu?

• Cuvinte cheie sursă: software-ul de bază știe cum arată gettext() și apelurile de funcții similare în mai multe limbaje de programare, dar ați putea la fel de bine să vă creați propriile funcții de traducere. Aici veți adăuga acele alte metode. Acest lucru va fi discutat mai târziu în secțiunea „Sfaturi”.

După setarea acestor proprietăți, Poedit va rula o scanare prin fișierele sursă pentru a găsi toate apelurile de localizare. După fiecare scanare, Poedit va afișa un rezumat al ceea ce a fost găsit și ce a fost eliminat din fișierele sursă. Noile intrări vor fi goale în tabelul de traducere, permițându-vă să introduceți versiunile localizate ale acelor șiruri. Salvați-l și un fișier .mo va fi (re)compilat în același folder și, până acum!, proiectul dvs. este internaționalizat!

Poedit poate sugera și traduceri comune de pe web și din fișierele anterioare. Este la îndemână, așa că trebuie doar să verificați dacă au sens și să le acceptați. Dacă nu sunteți sigur despre o traducere, o puteți marca ca Fuzzy și va fi afișată în galben. Intrările albastre sunt cele care nu au traducere.

4. Traducerea șirurilor

După cum probabil ați observat, există două tipuri principale de șiruri localizate: cele simple și cele cu forme de plural.

Cele simple au doar două casete: sursă și șir localizat. Șirul sursă nu poate fi modificat, deoarece Gettext/Poedit nu include posibilitatea de a modifica fișierele sursă; mai degrabă, va trebui să schimbați sursa în sine și să rescanați fișierele. ( Sfat: Dacă faceți clic dreapta pe o linie de traducere, aceasta va afișa un indiciu cu fișierele sursă și liniile în care este folosit acel șir.)

Șirurile de formă plurală includ două casete pentru a afișa cele două șiruri sursă și file pentru a putea configura diferitele forme finale.

Exemplu de șir cu formă de plural pe Poedit, care arată o filă de traducere pentru fiecare.

Ori de câte ori vă schimbați fișierele cu codul sursă și trebuie să actualizați traducerile, apăsați pe Reîmprospătare și Poedit va rescana codul, eliminând intrările inexistente, îmbinând pe cele care s-au schimbat și adăugând altele noi.

Poedit poate încerca, de asemenea, să ghicească unele traduceri, pe baza altora pe care le-ați făcut. Acele presupuneri și intrările modificate vor primi un marcator „Fuzzy”, care indică faptul că au nevoie de revizuire, afișat cu galben în listă.

De asemenea, este util dacă aveți o echipă de traduceri și cineva încearcă să scrie ceva despre care nu sunt siguri: doar marcați-l Fuzzy și altcineva îl va revizui mai târziu.

În cele din urmă, se recomandă să lăsați marcat „Vizualizare > Intrările netraduse mai întâi”, deoarece vă va ajuta să evitați uitarea oricăror intrări. Din acel meniu, puteți deschide și părți ale interfeței de utilizare care vă permit să lăsați informații contextuale pentru traducători, dacă este necesar.

Sfaturi si trucuri

Serverele web pot ajunge să vă memoreze fișierele .mo în cache.

Dacă rulați PHP ca modul pe Apache (mod_php), s-ar putea să întâmpinați probleme cu fișierul .mo care este stocat în cache. Se întâmplă prima dată când este citit și apoi, pentru a-l actualiza, poate fi necesar să reporniți serverul.

Pe Nginx și PHP5 este nevoie de obicei de doar câteva reîmprospătări de pagină pentru a reîmprospăta memoria cache a traducerii, iar pe PHP7 este rareori necesar.

Bibliotecile oferă funcții de ajutor pentru a menține codul de localizare scurt.

După cum preferă mulți oameni, este mai ușor să utilizați _() în loc de gettext() . Multe biblioteci personalizate i18n din cadre folosesc ceva similar cu t() , pentru a face codul tradus mai scurt. Cu toate acestea, aceasta este singura funcție care are o comandă rapidă.

S-ar putea să doriți să adăugați în proiectul dvs. altele, cum ar fi __() sau _n() pentru ngettext() , sau poate un _r() fantezist care să alăture apelurilor gettext() și sprintf() . Alte biblioteci, cum ar fi Gettext de la oscarotero, oferă și funcții de ajutor ca acestea.

În aceste cazuri, va trebui să instruiți utilitarul Gettext despre cum să extrageți șirurile din acele funcții noi. Nu-ți fie teamă, este foarte ușor. Este doar un câmp din fișierul .po sau un ecran de Setări în Poedit (în editor, acea opțiune se află în „Catalog > Proprietăți > Cuvinte cheie surse”).

Rețineți: Gettext cunoaște deja funcțiile implicite pentru multe limbi, așa că nu vă îngrijorați dacă lista pare goală. Trebuie să includeți în acea listă specificațiile noilor funcții, urmând acest format specific:

• Dacă creați ceva de genul t() , care pur și simplu returnează traducerea unui șir, îl puteți specifica ca t . Gettext va ști că singurul argument al funcției este șirul de tradus;

• Dacă funcția are mai mult de un argument, puteți specifica în care dintre ele este primul șir și, dacă este necesar, forma pluralului. De exemplu, dacă semnătura funcției noastre este __('one user', '%d users', $number) , specificația ar fi __:1,2 , ceea ce înseamnă că prima formă este primul argument, iar a doua formă este al doilea argument. Dacă numărul dvs. apare ca primul argument, specificația ar fi __:2,3 , indicând că prima formă este al doilea argument și așa mai departe.

După includerea acestor reguli noi în fișierul .po, o nouă scanare va aduce noile șiruri de caractere la fel de ușor ca înainte.

Faceți aplicația dvs. PHP multilingvă cu Gettext

Gettext este un instrument foarte puternic pentru internaționalizarea proiectului dvs. PHP. Dincolo de flexibilitatea sa care permite suportul pentru un număr mare de limbi umane, suportul pentru mai mult de 20 de limbaje de programare vă permite să vă transferați cu ușurință cunoștințele de utilizare cu PHP în alte limbi precum Python, Java sau C#.

În plus, Poedit poate ajuta la netezirea căii dintre cod și șirurile traduse, făcând procesul mai simplu și mai ușor de urmat. De asemenea, poate eficientiza eforturile de traducere partajată cu integrarea sa Crowdin.

Ori de câte ori este posibil, luați în considerare alte limbi pe care utilizatorii dvs. le-ar putea vorbi. Acest lucru este important mai ales pentru proiectele care nu sunt în limba engleză: vă puteți spori accesul utilizatorilor dacă îl lansați în engleză, precum și în limba maternă.

Desigur, nu toate proiectele au nevoie de internaționalizare, dar este mult mai ușor să porniți i18n în perioada incipientă a unui proiect, chiar dacă nu este necesar inițial, decât să o faceți mai târziu, în cazul în care ulterior devine o cerință. Și, cu instrumente precum Gettext și Poedit, este mai ușor ca niciodată.