Cheia de acces n sare lanagigarea in pagina. Sari la inceputul continutului.

Acest document e o traducere. In caz ca apare vreo eroare sau discrepanta, ultima versiune in Engleza este cea autoritativa. Copyright-ul original apartine W3C, dupa cum e aratat mai jos.

Traducator: Costea Marian

s_gotoW3cHome Internationalizare
 

Cand sa folosim negocierea limbajului

Cititorii vizati: webmasteri, administratori de server, si oricine doreste sa inteleaga mai bine negocierea de continut bazata pe limbaj.

Intrebare

Cand este in regula, sau nu, sa folosim negocierea limbajului?

Introducere

Negocierea limbajului este o functie a protocolulul HTTP protocol care permite serverului sa aleaga intre mai multe versiuni de limbaj a unei pagini, bazat pe URL-ul si preferintele de informatii trimise de browser(mai exact in headerul Accept-Language ). Acesta este diferit de selectarea paginii in functie de adresa IP a browserului sau de selectarea manuala de catre utilizator pe o pagina de selectare limba. Daca nu exista nici o potrivire intre preferintele exprimate de browser si limbajele disponibile pe server, va aparea o pagina de selectare a limbajului sau se va servi un limbaj implicit.

In multe cazuri,setarea utilizatorul initial pentru preferintele de limba este buna. De exemplu, daca aveti o versiune japoneza de browser, browserul presupune ca preferati paginile in japoneza, si trimite aceasta informatie catre server. Browserele mainstrean iti permit sa modifici preferintele de limbaj.Pentru mai multe informatii vezi Setarea limbajului preferat intr-un browser.

Acest articol pune sub semnul intrebarii cand este potrivit (sau nu) sa configuram negocierea de limbaj pe server.

Raspuns

Raspunsul scurt este: intotdeauna.

Un răspuns ceva mai lung este: aproape întotdeauna, dar nu singur.

Negocierea de limbaj nu functioneaza mereu cum ne dorim; sunt anumite tehnici pentru a compensa lipsurile; Una ar trebui sa prevada fluenta in navigare.

Lipsurile negocierii de limbaj

Negocierea de limbaj este evident un lucru bun, dar inainte de a o implementa la scara larga, este important sa ii intelegem limitele. Pentru a ilustra acestea, vom folosi exemplu unui site, www.example.be, care ofera continut in Flamanda, Franceza si Germana, care implementeaza negocierea de limbaj implicit in Flamanda pentru toate paginile. Vizitatorul nostry, Sylvia, va fi vorbitoare de limba italiana, dar se descurca si cu Germana. Se pot ivi mai multe situatii:

  1. Browserul Sylviei este configurat corect, exprimand prima data preferinta pentru Italiana , iar pentru Germana a doua. Italiana nu este disponibila la www.example.be, paginile sunt afisate in Germana , vizitatorul este in general multumit, totul este bine. Acesta este motivul pentru care exista negocierea de limbaj!
  2. Sylvia este o persoana fara cunostinte tehnice care nu a auzit niciodata de negocierea de limbaj HTTP si care nu a simtit niciodata nevoia de a modifica setarile browserului ei. Cea din urma este o versiune Italiana care (in mod corect) exprima in mod implicit o preferinta pentru Italiana. Accesand www.example.be, limba Italiana nu este disponibila si limba Flamanda implicita este afisata, chiar daca Germana este disponibila. Rau.
  3. Sylvia nu foloseste propriul ei browser, foloseste un computer dintr-un internet cafe din Moscova. Browserul de acolo este configurat pentru (sau implicit) in Rusa. Pagina este returnata in Flamanda din nou. Rau.

Speram ca imaginea este acum clara: Negocierea de limbaj nu returneaza tot timpul rezultatul dorit.

In plus, negocierea de limbaj nu este nici macar relevanta cand paginile nu sunt echivalente, i.e. nu au in esenta acelasi continut in diferite limbaje. ArticolulWebsituri Monolingve vs. multilingve lamureste putin acest lucru, a sevedea in special "Multilingv, acelasi continut" si "Multilingv, continut schimbat" sub-sectiuni. Notam totusi ca anumite masuri de adaptare culturala (e.g. schimbarea monedei) nu fac neaparat paginile does nonechivalente; Limitarea nonechivalentei negocierii limbajului exista cu adevarat atunci cand un site este adaptat astfel incat paginile in limbaje diferite nu mai corespund unele cu altele .

Cum compensam limitarile

In ciuda limitarilor, negocierea de limbaj este o functie folositoare si este preferabil sa fie implementata in situri multilingve. Dar carentele trebuiesc remediate. Pe scurt, este important sa se ofere mijloace vizitatorilor sasuprascrie alegerea automata de limbaj cand acesta este gresit. Asta inseamna implementarea unor elemente de interfata in pagina (le vom numicontroale de limbaj aici) care se leaga cu alte limbaje disponibile. Aceste controale trebuie sa fie in mod evident vizibile si pe intelesul unui vizitator care nu este familiarizat cu limbajul afisat implicit de site.

O intrebare care se ridica este: Ar trebui ca negocierea de limbaj si controalele de limbaj manuale sa fie implementate pentru toate paginile, sau doar pentru pagina principala? Cel mai bun raspuns este "toate paginile", cu exceptia acelora care nu sunt echivalente suficient. Negocierea de limbaj este buna deoarece, daca Jaap trimite un link intr-un email din www.example.be lui Pierre, Pierre va fi fericit sa primeasca versiunea Franceza, chiar daca Jaap a citit versiunea Flamanda. Controalele de limbaj trebuiesc de asemenea oferite, chiar daca negocierea este implementata sau nu. Daca negocierea este absenta, Pierre va avea nevoie de controale pentru a primi versiunea Franceza de la link-ul lui Jaap; chiar daca este acolo, Sylvia va trebui sa treaca manual pe Germana in situatiile 2 si 3 de mai sus.

Apropo, anumite situri aleg sa redea o pagina de selectie de limbaj cu scop special cand nu este nici o potrivire intre preferintele vizitatorului si limbajele disponibile (www.example.be ar putea face acest lucru in loc sa redea Flamanda). Aceasta are avantajul de a face situatia clara si de a nu oferi intaietate unui limbaj fata de restul, lucru care ar fi o problema sensibila politic. Din pacate, unele situri redau aceasta pagina speciala(ca si pagina principala) in loc sa implementeze negocierea de limbaj. Acest lucru forteaza pe toata lumea sa treaca prin acea pagina fara sa ofere nici un avantaj vizibil. Factori rai de design umani.

Navigare

Sa presupunem ca Sylvia viziteaza www.example.be si i se returneaza Flamanda(situatia 2 sau 3). Ea va da click apoi pe controlul German si va citi fara vreo problema reala. Dar apoi da click pe un link pentru a intra pe o pagina interesanta de pe site.. Oops, din nou Flamanda! Din fericire, controlul German este inca acolo, dar dupa cateva plimbari pe siteincepe sa devina frustrata. Nu poate www.example.be sa tina minte ca ea nu stie sa citeasca Flamanda ? Ce avem nevoie aici este putina persistenta a selectie de limbaj.

Sunt cateva metode ca www.example.be sa ofere aceasta persistenta. Ce sa alegem va depinde de ce sta la baza tehnologiei disponibileWhich pe server si de nivelul de efort care poate fi depus.

Daca situl implementeaza un mecanism de sesiune (de exemplu folosindcookies), atunci este o problema simple sa aranjam ca limbajul sa fie parte din sesiune. Odata ce Sylvia da click pe controlul German, acesta este stocat(ori in cookie ori pe server, pentru a fi comparat cu un numar de sesiune in cookie) si din acel moment ea va beneficia de pagini in Germana cand navigheaza pe site. Cookie-ul poate fi facut chiar si persistent(chiar daca aceasta face chestiunea de securitate mai acuta), astfel incat Sylvia sa beneficieze automat de pagini in Germanadata viitoare cand se va intoarce pe www.example.be. Situri care ofera un mecanisg de logare pot sa stocheze preferinte de limbaj ca parte a profilului utilizatorului, si sa ofere pagini in functie de preferinte. Negocierea de limbaj este apoi folosita numai pentru utilizatorii care nu s-au logat inca.

Alta cale de a diminua frustrarea este acea de a face toate paginile interne specifice limbii. In pagina principala Germana , linkurile catre alte pagini ar trebui sa fie de formahref="company/about.de.html" (in loc de company/about.html, care ar fi generice limbii)*. Navigarea este apoi fortata sa ramana in Germana, pana cand va fi suprascrisa de controalele de limbaj. Aceasta are cateva dezavantaje totusi. Unul este acela ca toate linkurile interne devin material de tradus, crescand astfel costul traducerii ca si potentialul pentru erori. Altul este ca daca Jaap trimite un link lui Pierre, URL-ul (luat din bara de adresa a browserului) va fi specifica limbajului; Pierre va primi atunci pagina in Flamanda. Nici unul din aceste dezavantaje nu sunt grave, totusi, deci folosirea linkurilor specifice limbii este probabil cea mai buna solutie daca persistenta nu poate fi oferita prin sesiuni sau mecanisme de profil.

* Retineti ca forme particulare de limbaj specifice si URL-uri de limbaj generic aratate aici(company/about.de.html vs company/about.html) depind de tehnologia folosita pe partea de server pentru implementarea negocierii de limbaj. Folosind Apache MultiViews, am prefera sa vedem company/about.html.de si company/about.html sau, renuntand la extensia .html complet, company/about.de si company/about.

Apropo

Headerul HTTP Accept-Language nu este singura sursa de informatie de limbaj disponibila. Toate browserele trimit de asemenea un header User-Agent identificand antetul browserului, numarul versiunii si in unele cazuri versiunea limbajului. Aceasta poate fi folosita pentru a ghici la limbajul preferat al utilizatorului daca headerul Accept-Language lipseste, dar este mai putin practica si mult mai limitata(un singur limbaj) decat Accept-Language. A se folosi cu mare grija.

Negocierea de limbaj este doar un aspect al negocierii de continut HTTP. Alte aspecte care pot fi automat negociate sunt tipurile media (i.e. formatul: HTML, PDF sau text simplu), criptarea de caractere si transferul criptarii (criptat, comprimat, etc.). Negocierea de limbaj este cea mai folositoare si mai folosita.

Spune-ne părerea ta (în Engleză).

Abonează-te la RSS feed.

Resurse noi

Noutăţi prima pagină

Twitter (Noutăţi prima pagină)

‎@webi18n

Alte materiale

Autor: François Yergeau. Traducator: Costea Marian.

XHTML 1.0 Valid!
CSS Valid!
Incodat cu UTF-8!

Tradus din engleza: 2004-02-26. Ultima modificare a traducerii: 2011-01-11 18:54 GMT

Pentru a vedea toate schimbarile documentului, cauta qa-when-lang-neg pe blogul i18n.