Polylang în WordPress: pagini și meniuri în două limbi

O traducere bună poate rămâne greu de folosit dacă butonul de contact duce în cealaltă limbă sau selectorul trimite mereu la homepage. În sens invers, o structură tehnică elegantă nu compensează texte netraduse. Acest tutorial propune un flux practic pentru un site WordPress de prezentare în română și engleză.

Ghidul nu instalează Polylang pe KEPA și nu declară automat compatibile rutele personalizate din pluginurile site-ului. Pentru semnalele lingvistice există ghidul hreflang. Aici ne concentrăm pe organizarea și verificarea conținutului în produsul Polylang, cu atenție la limitele temei și ale integrărilor.

1. Fă inventarul înainte să activezi a doua limbă

Listează paginile, articolele, categoriile, meniurile, formularele și textele globale. Separă conținutul salvat în WordPress de textul scris direct într-un plugin sau template. Nu presupune că o traducere a paginii va modifica automat un footer generat independent sau etichetele unui formular extern.

În exemplul nostru, site-ul are zece servicii, trei formulare și douăzeci de ghiduri. Alegem întâi un serviciu și formularul lui, nu douăzeci de articole. Scopul pilotului este să verificăm un traseu complet, inclusiv mesajele de eroare și confirmare. Volumul de text tradus nu reprezintă singur progresul implementării.

Salvează lista adreselor actuale și verifică un backup cu restaurare testată. Copia de test trebuie izolată de operațiuni reale: emailuri către clienți, plăți și integrări care pot crea comenzi. Nu folosi o copie a site-ului ca mediu sigur doar fiindcă are alt subdomeniu.

2. Stabilește cine traduce și cine aprobă

Pentru fiecare pagină, atribuie un responsabil de conținut și unul de verificare tehnică. Primul urmărește sensul, oferta și termenii comerciali. Al doilea verifică legăturile, structura și stările interfeței. O singură bifă „tradus” ascunde aceste două responsabilități și poate lăsa probleme neobservate.

Pregătește un glosar scurt cu numele serviciilor, butoanele și mesajele repetitive. Nu impune traducerea literală a fiecărui cuvânt; urmărește aceeași promisiune și aceeași acțiune. Un titlu englezesc poate avea altă lungime, iar un buton trebuie testat în ambele variante, nu tăiat ca să încapă într-un layout rigid.

În fișa pilotului, marchează stările: neînceput, redactat, revizuit, testat și publicabil. Separă aprobarea conținutului de data publicării. Această disciplină ajută când o ofertă se schimbă într-o singură limbă și cealaltă pagină trebuie actualizată, nu lăsată să promită alt serviciu.

3. Configurează limbile și verifică semnificația codurilor

Polylang permite administrarea limbilor din zona Languages. O limbă are nume, locale, cod și opțiuni de afișare; acestea nu au toate același rol. Locale-ul influențează traducerile WordPress, iar codul poate participa la structura URL-urilor. Verifică setările documentate pentru versiunea instalată. ^[1]

Pentru pilot, alege româna ca limbă a conținutului existent și engleza ca variantă nouă, numai dacă aceasta este situația reală. Nu redenumi o limbă folosită deja doar pentru a schimba steagul din meniu. Notează separat preferința vizuală și identificatorii tehnici, astfel încât o ajustare cosmetică să nu devină o schimbare de adrese.

În interfață, afișarea numelui limbii poate fi mai clară decât un steag singur. Limba și țara nu sunt aceeași informație. În testul nostru folosim etichete text recognoscibile și verificăm navigarea cu tastatura, nu numai aspectul butonului pe desktop.

4. Atribuie corect limba conținutului existent

Documentația Polylang descrie atribuirea limbii implicite conținutului fără limbă și editarea limbii individual sau în lot. Avertizează și că schimbarea limbii unui conținut deja tradus poate pierde asocierea cu traducerile existente. ^[2] De aceea, nu executa o schimbare globală fără inventar și probă pe un eșantion.

Verifică paginile esențiale după atribuirea limbii: homepage, contact, o pagină comercială și o categorie. Deschide și lista din administrare. Dacă unele materiale lipsesc dintr-un filtru, verifică atribuirea înainte să concluzionezi că au fost șterse. Păstrează ID-urile în fișa de lucru, nu doar titlurile.

Un titlu identic nu identifică sigur aceeași pagină. Înainte de asociere, confirmă ID-ul, starea și adresa. Această verificare simplă reduce riscul ca pagina „Contact” din engleză să fie legată de un formular vechi sau de o ciornă abandonată.

5. Decide structura URL-urilor o singură dată, controlat

Polylang oferă variante de identificare a limbii în URL, în funcție de permalinkuri: parametri, directoare sau configurații cu domenii/subdomenii. Opțiunile și efectele sunt descrise în modulul de modificare a adreselor. Dezactivarea pluginului poate schimba adresele care conțin informația lingvistică. ^[3]

În pilot propunem păstrarea adreselor românești existente, unde configurația permite, și un prefix clar pentru engleză. Aceasta este o alegere de proiect, nu o regulă universală. Verifică rezultatul efectiv înainte și după salvare, inclusiv slash-ul final și adresa homepage-ului.

Dacă adresele publicate se schimbă, documentează maparea și redirecționările relevante. Nu redirecționa toate paginile engleze către homepage-ul românesc ca soluție pentru lipsa traducerii. O schimbare de arhitectură trebuie tratată cu disciplina unei migrări de URL-uri, chiar dacă nu muți găzduirea.

6. Creează perechi de pagini, nu copii fără relație

Lucrează în perechi explicite: pagina serviciului în română și echivalentul ei în engleză. În fișa noastră, fiecare rând conține cele două ID-uri, cele două URL-uri și starea traducerii. O copie vizuală nu este suficientă dacă selectorul nu poate recunoaște relația dintre materiale.

Tradu conținutul relevant, inclusiv titlul, introducerea, descrierea meta și textele alternative ale imaginilor unde acestea trebuie localizate. Nu încărca imagini duplicate fără motiv numai pentru schimbarea limbii. Pentru o diagramă cu text încorporat, însă, cititorul are nevoie de varianta grafică potrivită sau de o explicație echivalentă accesibilă.

Verifică expresia comercială în piața vizată. Redactarea utilă nu înseamnă traducerea mecanică a titlului SEO românesc. Poți păstra sensul și structura serviciului, dar adaptează explicațiile și exemplele fără să inventezi oferte sau rezultate care nu există.

7. Construiește meniurile și testează selectorul de limbă

Selectorul Polylang urmărește traducerea paginii curente. Documentația explică opțiunile și comportamentul când traducerea lipsește, inclusiv trimiterea implicită către homepage-ul limbii respective. ^[4] Alege conștient comportamentul dorit; nu lăsa utilizatorul să creadă că va primi aceeași pagină când ajunge în altă parte.

În testul pilot, deschide serviciul românesc și schimbă limba. Confirmă că ajungi la serviciul englezesc, apoi revino. Repetă pe homepage și contact. Pentru o pagină netradusă, verifică dacă opțiunea este ascunsă sau dacă destinația alternativă este suficient de clară.

Un header custom poate construi meniul direct dintr-un registru propriu și poate necesita integrare separată. Dezvoltarea unei integrări personalizate trebuie să verifice sursa linkurilor, nu doar existența Polylang. Nu presupune că toate componentele KEPA vor deveni bilingve prin simpla activare a pluginului.

8. Tradu și textele care nu apar în editorul paginii

Polylang are o zonă dedicată traducerii unor șiruri înregistrate, precum texte ale site-ului sau ale componentelor compatibile. Nu orice text hardcodat apare automat acolo. ^[5] Dacă lipsește o etichetă, identifică sursa ei înainte să o înlocuiești printr-o regulă globală în HTML.

În lista noastră de verificare includem etichetele câmpurilor, butonul de trimitere, validarea, confirmarea și emailul. Nu este suficient ca pagina Contact să fie în engleză dacă mesajul de eroare este în română. Testează și o introducere incorectă, nu numai formularul completat perfect.

Pentru mesajele tranzacționale, livrarea emailurilor WordPress rămâne o problemă distinctă de limbă. Păstrează o adresă de test și verifică subiectul, textul și destinatarul. O traducere nu trebuie să modifice din greșeală adresa echipei sau să trimită notificarea către client în locul administratorului.

9. Verifică SEO pentru fiecare variantă

Deschide sursa paginii românești și a celei engleze. Verifică titlul, descrierea, canonical-ul, indicarea limbii și alternativele lingvistice. Nu adăuga încă un set de metadate dacă există deja unul generat de integrarea SEO. Mai întâi identifică cine produce fiecare element.

Folosește ghidul canonical și verificările hreflang pentru semnalele respective. Relația dintre traduceri nu se rezolvă prin trimiterea tuturor variantelor către aceeași pagină doar pentru că oferă același serviciu în limbi diferite. Testează și reciprocitatea legăturilor, nu exclusiv pagina principală.

Sitemapul și legăturile interne trebuie să reflecte conținutul publicat. Nu include traduceri goale doar pentru a afișa un număr mare de pagini. Pentru un site cu template-uri proprii, verificarea on-page trebuie făcută pe HTML-ul efectiv, nu presupusă din setările pluginului.

10. Testează cache-ul fără amestecarea limbilor

Accesează aceeași pagină în vizite anonime separate și verifică limba conținutului. Repetă schimbarea de limbă și revenirea dintr-un link extern. Dacă răspunsul depinde de cookie sau detectarea browserului, proiectarea cache-ului trebuie să țină cont de acest comportament. Nu forța publicarea aceleiași copii pentru răspunsuri diferite.

Cu adrese distincte, verificarea este mai ușor de documentat: URL, limbă, titlu, destinațiile meniului și antetele. Diagnosticul cache-ului Cloudflare explică diferența dintre o copie validă și un răspuns ocolit. Un HIT pe conținutul în limba greșită nu reprezintă o reușită.

Pe mobil, verifică meniul și încadrarea textelor responsive cu traducerea cea mai lungă. Nu micșora excesiv fontul ca să păstrezi aceeași înălțime. Layoutul trebuie să suporte conținutul real, inclusiv diacritice, mesaje de două rânduri și butoane cu etichete mai ample.

11. Nu extinde automat pilotul la WooCommerce

Polylang documentează separat integrarea pentru WooCommerce. ^[6] Produsele, variațiile, emailurile și traseul comenzii adaugă verificări care nu există pe un site simplu de prezentare. Nu considera testul unui articol drept dovadă că stocurile și checkout-ul sunt corect localizate.

Pentru un magazin, pregătește comenzi de test în fiecare limbă și verifică identificatorii produselor în integrări. Importul catalogului și sincronizarea cu marketplace-uri nu trebuie să dubleze operațiunile doar pentru că există două versiuni de prezentare. Cerința se analizează pe flux, nu pe culoarea selectorului.

12. Predă o procedură de întreținere, nu doar accesul

La finalul pilotului, documentează cine actualizează traducerea când se schimbă pagina principală. Leagă această sarcină de procesul editorial existent. Nu presupune că două versiuni rămân sincronizate fiindcă au fost publicate în aceeași zi. Prețurile, serviciile și condițiile se pot modifica separat.

Propunem o verificare periodică pe un eșantion stabil: homepage, serviciu, contact, categorie și articol. Notează textele rămase în altă limbă, legăturile rupte și diferențele de ofertă. O listă scurtă repetabilă este mai utilă decât o verificare amplă executată o singură dată la lansare.

Înainte de dezactivare sau înlocuire, revino la inventarul adreselor. Planul de revenire trebuie să explice ce se întâmplă cu URL-urile și asocierea traducerilor. Nu șterge datele pentru a „curăța” instalarea fără o copie și o procedură de recuperare.

Matrice de acceptanță pentru un traseu RO–EN

Înainte de extinderea pilotului, pregătește o matrice cu trei pagini și două limbi. Pentru fiecare combinație verifici adresa, titlul, meniul, butonul principal și formularul aferent. O pagină primește aprobarea numai dacă destinațiile sale sunt coerente. Traducerea izolată a textului nu este suficientă atunci când următorul pas duce într-o pagină greșită sau neterminată.

În proba de desktop, începi de pe homepage-ul românesc și ajungi la serviciu. Schimbi în engleză și verifici echivalentul, apoi deschizi contactul. În proba de mobil, pornești direct din URL-ul englezesc, fără vizita anterioară în română. Aceste două trasee pot expune probleme diferite de meniuri, preferințe sau adrese generate de componentele site-ului.

Adaugă un caz intenționat fără traducere. Notează comportamentul selectorului și întreabă o persoană care nu a construit pagina dacă înțelege unde va ajunge. Dacă interfața promite aceeași pagină, dar duce la homepage, ai o problemă de orientare chiar dacă răspunsul HTTP este corect. Rezolvarea poate fi o opțiune clară, nu obligatoriu traducerea imediată a întregii biblioteci.

Testează și editarea ulterioară. Modifică pe staging o propoziție din pagina românească și verifică dacă procesul echipei semnalează necesitatea revizuirii englezei. Nu presupune sincronizare editorială automată. Dacă ai activat copierea sau sincronizarea unor câmpuri, verifică exact ce este comun și ce trebuie să rămână diferit, pentru a nu suprascrie traducerile aprobate.

La predare, păstrează o listă de componente care necesită integrare suplimentară: meniuri din cod, rute virtuale, formulare și imagini cu text. Lista nu este un defect al traducătorului; este inventarul tehnic al proiectului. Ea permite estimarea corectă a lucrului și previne promisiunea că simpla activare a unui plugin transformă automat orice site custom într-un site bilingv complet.

Întrebări frecvente

Polylang traduce automat toate pluginurile custom?

Nu presupune acest lucru. Conținutul nativ, șirurile înregistrate și HTML-ul generat de cod sunt situații diferite. Testează componentele reale și cere integrare explicită unde sursa textului sau a URL-ului nu urmează mecanismele compatibile.

Trebuie să public toate traducerile simultan?

Poți organiza lansarea în etape, dar fiecare traseu public trebuie să fie coerent. O pagină engleză care trimite toate acțiunile în română este incompletă din perspectiva utilizatorului. Pilotul trebuie să includă și destinațiile, nu numai articolul de început.

Ce verific înainte de lansare?

Asocierea paginilor, meniurile, formularele, metadatele, adresele și cache-ul. Adaugă testul de revenire între limbi și un scenariu fără traducere disponibilă. Aprobarea finală trebuie să includă atât conținutul, cât și funcționarea.

Surse și documentație

Pilotul și fișele descrise sunt exemple editoriale KEPA. Articolul nu activează Polylang și nu certifică compatibilitatea site-ului. Surse consultate la 25 septembrie 2026.

1. Polylang: configurarea limbilor
2. Polylang: atribuirea limbii conținutului
3. Polylang: structura URL-urilor
4. Polylang: selectorul de limbă
5. Polylang: traducerea șirurilor
6. Polylang: instalarea integrării WooCommerce