A böngészőből jövő kérés nyelvi beállításai

Kérdés

Jó ötlet a böngészőből jövő kérés nyelvi beállításait használni a felhasználó helyének megadására?

Background

Néhány webes alkalmazás számára hasznos lenne társítani a helyszínt a felhasználókhoz, akik látogatják az oldalt. A hely hozzárendelése lehetővé tenné számukra, hogy az információt a helyi formátumban kapják meg. Ezeknek az információknak egy része megegyezik a hagyományos szoftvereknél felmerülő lokalizációs kérdésekkel, úgyis, mint:

Másrészről további információ származhat a hely meghatározásából, további tudás felhasználásával, úgyis, mint:

Mivel ezek egyike sem szerepel a HTTP protokollban, ezért sok webfejlesztő használja a böngészőből jövő kérés nyelvi beállításait (Accept-Language fejlécet) a felhasználó területi beállításainak megállapítására.

A böngészőből jövő kérés nyelvi beállításai egy információ a felhasználó nyelvi beállításairól a HTTP-n keresztül, ha a felhasználó dokumentumot kér. A népszerű böngészők lehetővé teszik ezen nyelvi beállítások felhasználó általi változtatását. Az érték önmagában a BCP 47 alapján meghatározott, jellemzően két vagy három betűs nyelvi kód (pl. fr franciára), amit az opcionális alkód követ, ami például az országot jelöli (pl. fr-CA jelenti a kanadai franciát).

A kérdés az, hogy ez az információ megfelelő-e a felhasználó területi beállításainak meghatározásához.

Válasz

A böngészőből jövő kérés nyelvi beállításának eredeti célja az volt, hogy meghatározza a felhasználó nyelvét. Amióta azonban egyre több alkalmazásnak kell tudnia a felhasználó elhelyezkedését, az Accept-Language az, amit a gyakorlatban ennek az információnak meghatározására is használnak. Az, hogy a böngészőből jövő kérés nyelvi beállítása egyedül határozza meg a felhasználó elhelyezkedését, nem jó ötlet. Ha kizárólag csak az Accept-Language-et használjuk, esetleg gátoljuk a felhasználót a területi beállítás tetszés szerinti változtatásában.

Első körben az a böngészőből jövő kérés nyelvi beállításai értékének területi beállításokra való használata nem rossz ötlet, azonban meg kell bizonyosodnunk róla, hogy ha szükséges, akkor a nyelv változtatható, és a kulturális beállításai pontosíthatóak. Az eredményeket adatbázisban vagy HTTP-sütiben tároljuk a későbbi látogatásokhoz.

Néhány lehetséges teendő:

Mellesleg

Szintén ajánlatos az Accept-Language fejléc használatánál a felhasználó nyelvének megadásával kezdeni, és nem a terület megadásával. De még ebben az esetben is tudnunk kell ennak korlátait, és lehetőséget kell adnunk a felhasználónak arra, hogy felülírja feltételezéseinket. Az előbb felsorolt problémák erre is vonatkozhatnak.

Még ha mi nem is teszünk feltételezéseket a területről vagy régióról, tudnunk kell, hogy a programozási környezet használhatja ezt az információt. Sok webszerver, szerver oldali szkript nyelv és a működési környezet alapvetően értelmez és következtet az Accept-Language eredeti területi objektumaira. Például, a .NET a böngészőből jövő kérés nyelvi beállításait használja az alap CultureInfo beállításához, a Java Servlet biztosít egy getLocale() és getLocales() párt, ami előkészíti a böngészőből jövő kérés nyelvi beállításait, és így tovább. Ezek az objektumok nagyon hasznosak a források és más „nyelvi preferencia” anyagok megszerzésében. Ám ahogy már az előbb utaltunk rá, kevésbé hasznos a felhasználó helyi beállításainak részletes megállapításánál vagy a nemzetközi oldal tervezésekor. Az es-MX nyelvi preferenciája nem feltétlenül jelenti, hogy a postai cím formátumát át kellene alakítani, érvényesíteni mexikói címekké. A felhasználó talán még mindig az USA-ban (vagy bárhol máshol) él.