Cand sa folosim negocierea limbajului

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 disponibile 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.