Cum să traduci fișiere .po Drupal cu AI
Majoritatea oamenilor asociază fișierele .po cu WordPress, dar formatul gettext precede WordPress cu decenii și susține traducerea interfețelor în întreaga lume open-source. Drupal este unul dintre cei mai mari utilizatori ai săi. Dacă rulezi un site Drupal multilingv, fiecare etichetă de meniu, descriere de câmp, mesaj de eroare și șir de module trece prin fișiere .po exact așa cum se întâmplă în WordPress, just cu un dialect diferit al substituenților și un flux de lucru de import diferit. Și la fel ca WordPress, în momentul în care site-ul tău depășește câteva șiruri de caractere, traducerea manuală a acestor fișiere devine un blocaj.
Acest ghid este despre cum să traduci fișiere po Drupal cu AI fără a strica elementele care fac Drupal, Drupal. Vom analiza sistemul de traducere al Drupal, de unde provin de fapt șirurile de caractere, sintaxa substituenților care diferă de WordPress și care trebuie absolut păstrată, precum și ciclul complet de export, traducere și re-import, inclusiv comenzile drush care îl fac repetabil.
Cum funcționează sistemul de traducere al Drupal
Drupal gestionează traducerea interfeței prin modulul locale de bază (numit uneori „Traducere interfață” în Drupal-ul modern). Odată activat, acesta gestionează o tabelă de bază de date cu șiruri sursă și traducerile acestora pe limbă și poate importa și exporta aceste traduceri ca fișiere .po standard gettext.
Interfața de administrare se găsește la /admin/config/regional/translate. De acolo poți căuta șiruri netraduse, le poți edita inline și, esențial, poți importa un fișier .po pentru a încărca în masă traduceri sau poți exporta starea curentă într-un fișier .po pentru editare offline. Acest ciclu export/editare/import este fluxul de lucru pe care îl optimizăm.
Spre deosebire de WordPress, unde fiecare plugin și temă își livrează propriile fișiere .po și .mo într-un director languages/, Drupal centralizează șirurile interfeței în baza sa de date și tratează .po ca format de interschimb. Exporți, lucrezi la fișier și îl imporți înapoi. Pasul de compilare .mo pe care îl necesită WordPress este gestionat intern.
De unde provin șirurile de caractere
Șirurile Drupal provin din trei locuri, iar o traducere completă trebuie să le acopere pe toate:
- Core livrează mii de șiruri de caractere traducibile pentru interfața de administrare, formulare și mesaje de sistem.
- Modulele contrib (Views, Webform, Commerce și celelalte) înregistrează fiecare propriile șiruri de caractere prin funcția
t(). - Temele contribuie cu șiruri de șabloane, etichete de regiuni și descrieri ale setărilor temei.
Când exporți din /admin/config/regional/translate, poți limita exportul la șiruri traduse, netraduse sau toate. Pentru o nouă rundă de traducere, exportarea doar a șirurilor netraduse îți oferă un fișier .po concentrat, cu exact munca rămasă.
O consecință practică a acestei structuri cu trei surse: munca ta de traducere nu este niciodată cu adevărat „terminată”. De fiecare dată când adaugi un modul contrib, activezi o nouă funcționalitate sau actualizezi Drupal core, un nou lot de intrări msgid netraduse apare în tabelele de localizare. Acesta este motivul pentru care echipele Drupal tratează traducerea ca pe un proces recurent, mai degrabă decât o sarcină de lansare unică. Același ciclu de export, traducere, re-import rulează la fiecare implementare care implică module, iar cu cât acest ciclu este mai rapid, cu atât se acumulează mai puțină „datorie de traducere” între versiuni.
De asemenea, merită menționat că Drupal poate extrage automat traduceri contribuite de comunitate de pe localize.drupal.org pentru modulele core și cele populare contrib. Acestea acoperă șirurile comune, dar rareori acoperă modulele tale personalizate, tema ta sau formulările specifice proiectului pe care site-ul tău le utilizează de fapt. Decalajul dintre traducerea comunității și un site complet localizat este exact munca pe care o soluționează rapid o trecere cu AI.
Substituenții Drupal nu sunt substituenți WordPress
Iată cel mai important lucru de înțeles înainte de a trimite orice fișier .po Drupal unui traducător AI: Drupal nu folosește substituenții de tip printf %s și %1$s care domină WordPress. Funcția t() a Drupal folosește trei prefixe distincte de substituenți, fiecare cu un comportament diferit de evadare:
@variable— valoarea este evadată HTML, implicitul sigur pentru textul introdus de utilizator.%variable— valoarea este evadată și învelită în marcajul de accentuare<em>.:placeholder— folosit pentru atributele URL, trecut prin sanitizarea URL-ului.
Un șir sursă tipic Drupal arată astfel în fișierul .po exportat:
#: 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 ""
Dacă un traducător schimbă @count în @cuenta, înlocuiește @name cu cuvântul tradus pentru „name” sau inserează un spațiu transformând @count în @ count, substituentul nu se mai potrivește cu ceea ce transmite apelul t(). Drupal va tipări apoi token-ul literal @count pe pagină în loc de numărul real. Traducerea pare terminată, dar site-ul este vizibil stricat.
Aceasta este aceeași clasă de erori care afectează șirurile %s din WordPress, iar principiul general îl acoperim în detaliu în cum să traduci fișiere PO fără a strica variabilele de cod. Particularitatea Drupal este pur și simplu că există trei stiluri de substituenți în loc de unul singur, iar un instrument de traducere trebuie să le recunoască pe toate.
De ce eșuează aici traducătorii generici
Lipește acel șir node.module într-o casetă de traducere automată generică și vei obține frecvent @count alterat, %date legat de <em> localizat într-un token diferit sau formele de plural colapsate într-una singură. Niciunul dintre aceste instrumente nu a fost construit având în vedere semantica gettext. Ele traduc text; nu înțeleg că @count este un contract cu codul aplicației.
Un pipeline de traducere conștient de gettext, cu Blocare de sintaxă, tratează @variable, %variable și :placeholder ca token-uri imutabile. Acestea sunt blocate înainte de traducere și restaurate după, astfel încât propoziția înconjurătoare este tradusă, în timp ce substituenții trec neatinsi. Aceeași blocare acoperă %s și %1$s din WordPress, {{name}} din i18next și HTML-ul inline, motiv pentru care un singur instrument poate servi un proiect Drupal, Symfony sau Laravel la fel de ușor ca unul WordPress. Formele de plural Drupal prin msgid_plural sunt păstrate ca forme de plural, nu aplatizate, ceea ce contează deoarece limbile Drupal pot avea oriunde de la una la șase variante de plural.
Există și un mod de eșec mai subtil care merită menționat. Șirurile Drupal încorporează frecvent marcaje și linkuri inline în interiorul textului traducibil, cum ar fi Read the <a href=":url">documentation</a> unde :url este un substituent, iar etichetele <a> trebuie să supraviețuiască. Un traducător care nu înțelege structura poate traduce atributul href, poate omite eticheta de închidere sau poate localiza numele substituentului. AI-ul conștient de context care citește întregul șir ca o unitate, combinat cu blocarea token-urilor, menține atât marcajul, cât și contractul :url intacte, traducând doar textul „documentation” lizibil de către om, care se află între ele.
Ciclul Export, Traducere, Re-Import
Fluxul de lucru repetabil are trei etape, iar drush face exportul și importul scriptabile, astfel încât să nu dai clic prin interfața de administrare de fiecare dată.
Pasul 1: Exportați fișierul PO
Poți exporta din interfață la /admin/config/regional/translate alegând o limbă și un scop de export, sau o poți face din linia de comandă. Modulul locale expune exportul prin serviciile de traducere ale Drupal, iar majoritatea echipelor îl scriptează. O invocare tipică drush pentru a declanșa un import de traducere (inversul, pe care îl folosim în pasul trei) arată astfel:
# 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
Pentru partea de export, formularul de export din administrare produce fișierul .po; multe echipe învelesc serviciul de export local într-o mică comandă Drush personalizată pentru automatizare completă. Oricum, vei ajunge cu un fișier .po standard gettext care conține intrările tale msgid netraduse.
Pasul 2: Traduceți fișierul
Aceasta este etapa în care AI înlocuiește ore întregi de editare manuală. Încarcă fișierul .po exportat la un traducător în cloud, alege limba țintă și lasă-l să proceseze. Deoarece fișierele .po Drupal pentru un site mare depășesc frecvent 10MB odată ce core, contrib și temele sunt combinate, Smart Batching contează aici: fișierul este împărțit în bucăți, tradus și reasamblat fără ca tu să-l împarți manual sau să atingi limitele de dimensiune. Rezultatul este un fișier .po complet, cu fiecare msgstr completat și fiecare substituent @count, %date și :url exact unde a început.
Pasul 3: Re-Importați în Drupal
Importă fișierul tradus înapoi prin /admin/config/regional/translate sau prin comanda drush locale:import prezentată mai sus, apoi reconstruiește memoria cache. Drupal fuzionează traducerile în tabelele sale locale, iar șirurile de caractere apar imediat pe tot site-ul. Rulează ciclul din nou ori de câte ori adaugi un modul sau actualizezi core-ul, deoarece fiecare aduce noi șiruri netraduse.
Un detaliu de import de reținut: flag-ul --override controlează dacă traducerile primite le înlocuiesc pe cele existente. Utilizează --override=all atunci când vrei ca fișierul tradus cu AI să fie autoritar, sau o setare mai conservatoare dacă ai ajustat manual anumite șiruri în interfața de utilizare Drupal pe care nu vrei să fie suprascrise. Pentru majoritatea pipeline-urilor automate, tratarea fișierului .po ca sursă de adevăr și suprascrierea a tot ceea ce menține sistemul previzibil: fișierul din controlul versiunilor este ceea ce afișează site-ul, punct.
Pentru site-urile multilingve cu mai multe limbi țintă, ciclul rulează o dată pentru fiecare limbă. Exporți setul netradus, îl traduci în germană, îl imporți; exporți din nou, traduci în spaniolă, îl imporți; și așa mai departe. Deoarece fiecare limbă este un fișier .po independent, le poți rula în paralel, iar un traducător în cloud care le procesează concurent transformă ceea ce înainte era o săptămână de muncă a unui contractor într-o singură după-amiază.
Fișierele PO Drupal sunt un format printre mai multe
Merită menționat că gettext .po nu este singura modalitate prin care Drupal gestionează traducerea. Entitățile de configurare și conținut pot fi, de asemenea, schimbate ca XLIFF, care este standardul pe care modulul Translation Management Tool (TMGMT) se bazează pentru fluxurile de lucru ale furnizorilor de traduceri profesionale. Dacă localizarea ta Drupal se realizează prin XLIFF, mai degrabă decât prin fișiere .po de interfață, principiile de păstrare a substituenților sunt identice, dar structura fișierului diferă, iar noi acoperim această cale în traducerea fișierelor XLIFF pentru Drupal, Symfony și Angular.
Pentru stratul de traducere a interfeței, însă, .po rămâne instrumentul principal. Ciclul export, traducere AI, re-import transformă o sarcină manuală de mai multe zile în câteva minute de procesare, iar atâta timp cât instrumentul pe care îl folosești înțelege cu adevărat substituenții gettext, contractele tale @variable supraviețuiesc intacte, iar site-ul tău Drupal rămâne funcțional în fiecare limbă pe care o oferi.
Ești gata să-ți traduci fișierele
.poDrupal fără a strica niciun singur@variable? Încearcă SimplePoTranslate gratuit — nu este necesar un card de credit. Nivelul gratuit gestionează fișierele standard gettext.poși.potcu blocare completă de sintaxă, astfel încât substituenții tăi Drupal trec exact așa cum se așteaptă codul.