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?
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.
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ő:
de-DE
, de-CH
vagy de-AT
kóddal ahhoz, hogy jelezzük, hogy németországi, svájci vagy osztrák a területi beállítás. Másrészről ez
azt is jelenti, hogy csak de
kódot kapunk a német nyelvre. Ha azt tervezzük, hogy a régiót is használni szeretnénk annak eldöntésére, hogy milyen pénznemet használjunk, akkor
ez nem elegendő. Az adott körülmények lehetőséget adhatnak olyan feltételezésekre, mint "Németországban 83 millió, Svájcban 8 millió ember él
de csak 65%-uk beszél németül, Ausztria 8 milliós, a felhasználó valószínűleg eurót használ. Ha téves a feltételezés, akkor német nyelvű ügyfeleinknek 5,4%-ánál
azaz több mint 5 millió ember esetében tévedhetünk." Dönthetünk úgy, hogy felvállaljuk ezt a kockázatot. Ám sokkal egyszerűbb
a felhasználótól több információt kérni. Ráadásul az ilyen típusú feltevés még kockázatosabb például a spanyol vagy az angol esetében.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.