Un fișier introdus, cinci formate obținute: Cum să-ți protejezi traducerile WordPress pentru viitor

Ai petrecut trei săptămâni traducând tema ta WordPress în spaniolă. Fișierul .po este perfect — fiecare șir verificat, fiecare variabilă intactă, fiecare formă de plural corectă. Apoi, clientul tău decide să migreze de la o temă PHP clasică la o configurație headless cu React pe frontend.

Deodată, fișierul tău .po devine inutil. Aplicația React are nevoie de .json. Widget-urile PHP vechi încă au nevoie de .mo. Freelancer-ul care se ocupă de aplicația mobilă vrea .xliff. Și nimeni nu are timp să re-traducă 4.000 de șiruri în trei formate diferite.

Acesta nu este un caz izolat. Este realitatea dezvoltării moderne WordPress, unde temele vin cu componente PHP și JavaScript, plugin-urile folosesc un amestec de Gettext și i18next, iar clienții își schimbă părerea despre arhitectură mai des decât își schimbă parolele.

De ce formatele de fișiere de traducere contează mai mult ca niciodată

Acum cinci ani, traducerea WordPress era simplă. Aveai un fișier .po (sursă lizibilă de om) și un fișier .mo (binar compilat). Asta era tot. Fiecare temă, fiecare plugin, fiecare instrument de traducere vorbea aceeași limbă.

Astăzi, ecosistemul WordPress folosește cel puțin cinci formate de fișiere de traducere în producție:

Cele cinci formate pe care trebuie să le cunoști

.po (Portable Object) — Formatul sursă lizibil de om folosit de GNU Gettext. Conține șiruri originale (msgid) și traducerile lor (msgstr). Acesta este ceea ce editează traducătorii.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — Versiunea binară compilată a unui fișier .po. WordPress citește fișierele .mo la runtime folosind load_textdomain(). Mai rapid decât analizarea .po la runtime, dar nu este editabil de om.

.json (JavaScript Object Notation) — Folosit de wp_set_script_translations() pentru traducerile bazate pe JavaScript în blocurile Gutenberg, componentele React și temele moderne. WordPress se așteaptă la o structură JSON specifică cu cheile locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Un format din ce în ce mai popular pentru temele și plugin-urile care folosesc încărcarea traducerilor în stil Laravel. Unele teme WordPress moderne ocolesc complet Gettext și încarcă traducerile din array-uri PHP pentru performanță.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — Standardul industrial pentru schimbul de traduceri între diferite instrumente și platforme. Folosit de instrumente CAT (Computer-Assisted Translation) precum memoQ, Trados și Memsource. Esențial atunci când lucrezi cu traducători umani profesioniști.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Problema: Dependența de format

Majoritatea instrumentelor de traducere produc un singur format de ieșire. Poedit îți oferă .po și .mo. WPML stochează traducerile în baza de date (deloc în fișiere). Weglot păstrează traducerile pe serverele lor într-un format proprietar. Chiar și platformele TMS precum Crowdin și Lokalise te obligă să configurezi manual formatele de export pentru fiecare proiect.

Aceasta creează dependență de format — traducerile tale sunt prinse în formatul produs de instrumentul tău actual. Când cerințele tale se schimbă, te confrunți cu două opțiuni:

1. Re-traduci totul în noul format (scump, consumă mult timp și pierzi orice corecții manuale)
2. Scrii scripturi de conversie personalizate (predispuse la erori, mai ales pentru forme de plural complexe și variabile)

Niciuna dintre opțiuni nu este bună. Ambele irosesc timp și bani. Ambele introduc riscuri.

Scenarii reale în care dependența de format dăunează

Scenariul 1: Modernizarea temei. Tema clientului tău este reconstruită cu blocuri Gutenberg. Șabloanele PHP vechi foloseau fișiere .mo. Noile blocuri au nevoie de .json pentru wp_set_script_translations(). Cele 3.000 de șiruri traduse trebuie să existe în ambele formate în timpul tranziției.

Scenariul 2: Flux de lucru al agenției. Gestionezi 20 de site-uri ale clienților. Unele folosesc teme clasice (.mo). Unele folosesc configurații headless (.json). Unul folosește un framework personalizat care citește array-uri PHP. Ai nevoie de aceleași traduceri în formate diferite pentru diferiți clienți.

Scenariul 3: Revizuire profesională. Traducerile tale AI sunt precise în proporție de 95%, dar vrei ca un vorbitor nativ să revizuiască restul de 5%. Traducătorii profesioniști folosesc instrumente CAT care importă .xliff. Trebuie să-ți exporți traducerile în .xliff, să le trimiți pentru revizuire și să îmbini corecțiile înapoi.

Scenariul 4: Migrarea platformei. Clientul tău se mută de la WordPress la o aplicație Node.js personalizată. Noua aplicație folosește i18next și are nevoie de fișiere .json. Cele 5.000 de șiruri traduse în format .po trebuie convertite — fără a pierde nicio variabilă sau formă de plural.

Soluția: Traduci o dată, obții fiecare format

SimplePoTranslate adoptă o abordare diferită. Când încarci un fișier .po, .pot, .json sau .xliff și rulezi o traducere, primești înapoi un ZIP care conține toate cele cinci formate:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Aceasta nu este o „funcție premium” blocată în spatele unui nivel enterprise. Fiecare plan plătit — Pro (19 USD/lună) și Lifetime (399 USD o singură dată) — include toate cele cinci formate de ieșire în fiecare lucrare de traducere.

De ce contează acest lucru pentru protejarea viitoare

Când ai toate cele cinci formate de la început, nu mai trebuie să re-traduci niciodată. Traducerile tale sunt un activ care se adaptează la orice cerință tehnică:

• Clientul migrează de la clasic la Gutenberg? Implementează fișierul .json.
• Noul dezvoltator preferă array-uri PHP? Dă-i fișierul .php.
• Traducătorul profesionist vrea să revizuiască? Trimite fișierul .xliff.
• Treci la un alt CMS? Fișierele .json și .xliff sunt agnostice de platformă.

Traduci o dată. Formatele sunt gata când ai nevoie de ele.

Cum funcționează fiecare format în WordPress

Știind ce fișier unde merge este esențial pentru o implementare curată.

Implementarea fișierelor .mo (teme și plugin-uri PHP clasice)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress le încarcă automat când limba site-ului se potrivește. Nu este necesar niciun plugin. Zero overhead al bazei de date. Aceasta este abordarea care oferă cea mai bună performanță.

Implementarea fișierelor .json (blocuri Gutenberg și componente JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Numele fișierului include handle-ul scriptului și un hash MD5. WordPress le potrivește când apelezi wp_set_script_translations() în pluginul sau tema ta. Dacă construiești blocuri Gutenberg, acesta este fișierul care face ca etichetele și descrierile blocurilor tale traduse să apară corect.

Utilizarea fișierelor .xliff (flux de lucru de revizuire profesională)

Fișierele .xliff nu sunt implementate în WordPress. Ele sunt folosite ca un format de schimb atunci când trebuie să trimiți traduceri unui revizor profesionist sau să le importezi într-un instrument CAT. Fluxul de lucru arată astfel:

1. Încarcă .po în SimplePoTranslate și obține .xliff în ZIP
2. Trimite .xliff traducătorului sau revizorului tău
3. Primește .xliff corectat înapoi
4. Încarcă .xliff corectat în SimplePoTranslate și obține .mo și .json actualizate

Acest flux de lucru dus-întors păstrează fiecare variabilă și formă de plural, deoarece Blocarea sintaxei SimplePoTranslate le protejează în fiecare etapă.

Testul de dependență de furnizor

Iată un test simplu pentru a determina dacă fluxul tău de lucru actual de traducere are o problemă de dependență:

1. Poți exporta traducerile tale ca fișiere .po standard chiar acum?
2. Dacă anulezi abonamentul la instrumentul tău de traducere astăzi, păstrezi fiecare șir tradus?
3. Poți importa traducerile tale într-un instrument sau platformă complet diferită fără a re-traduce?

Dacă răspunsul la oricare dintre acestea este „nu”, ești dependent. Servicii precum Weglot și GTranslate pică toate cele trei întrebări — anulează abonamentul și traducerile tale dispar. WPML stochează traducerile în baza de date, făcând exportul posibil, dar dureros. Chiar și instrumentele desktop precum Poedit trec testul pe hârtie, dar te limitează doar la .po și .mo.

Cu SimplePoTranslate, răspunsul la toate cele trei întrebări este „da”. Descarci fișiere standard în cinci formate. Sunt ale tale. Șterge-ți contul mâine și fiecare traducere pe care ai făcut-o vreodată va funcționa în continuare.

Construirea unei biblioteci de traduceri agnostice de format

Pentru agențiile și dezvoltatorii care gestionează mai multe proiecte, cea mai inteligentă abordare este construirea unei biblioteci de traduceri — un depozit Git sau un folder partajat unde stochezi fișierele traduse pentru fiecare proiect al clientului.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Când un client are nevoie de un format nou, îl ai deja. Când un client își schimbă platforma, traducerile tale migrează cu zero efort. Când un nou dezvoltator se alătură echipei, poate vedea exact ce a fost tradus și în ce formate.

Aceasta este ceea ce înseamnă de fapt „protejat pentru viitor” — nu prezicerea ce tehnologie vor folosi clienții tăi anul viitor, ci asigurarea că traducerile tale funcționează cu orice aleg ei.

Ești gata să nu te mai îngrijorezi de formatele de fișiere? Încearcă SimplePoTranslate gratuit — încarcă un fișier, obține cinci formate înapoi. Fără scripturi de conversie, fără re-traducere, fără dependență.