[db-wg] Status of the language: attribute

20 mar 2013 kl. 16:32 skrev Shane Kerr:

> Jan-Erik,
> 
> On Wed, 20 Mar 2013 11:04:47 +0200
> Jan-Erik Eriksson <jee at alcom.ax> wrote:
>> Our special situation as a Swedish speaking area with the country of
>> Finland have and still are imposing great challenges for s in the
>> on-line world. Typically web services, ads, media and other on-line
>> content is presented to our users in the wrong language.
> 
> HTTP has had an "Accept-Language" option since HTTP/1.1, almost 14
> years old now:
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
> 
> It seems to be supported by all of the popular browsers, and presumably
> is straightforward to use on the web server side.
> 
> Apparently this feature is not used?

To some extent, I believe that it is. The question is, is that sufficient?


> The reason I bring this up is because it seems like a much, MUCH better
> way of getting the correct language to the user. AIUI operating systems
> already set this to the system language by default, but of course users
> can tweak it.
> 
>> To solve these issues today the only way is to approach the presenter
>> of that content, for instance Google, and lobby for them to handle
>> this situation. As you all understand, this task is impossible
>> considering the number of parties that we would need to contact.
> 
> Google in particular is well-known for being ridiculous regarding
> localization. Anyone who has traveled has faced the annoyance of being
> presented with a screen of text in a language (or even a character set)
> that they can't read. For example, if I was to visit the Åland Islands
> I would not want Finish or Swedish. :)

Well, if you were roaming in our network from your mobile, your packet data connection would receive an IP from your home operator and that IP would (hopefully) have your preferred language attribute set to the correct value. :)

If you were using WiFi at the hotel, the situation would be different.

That said, I understand your point and agree that the HTTP header would give a better level of granularity. But that doesn't mean that it removes the justification for tools that work at a higher level. 

> I guess my question is that if companies are going to ignore browser
> settings - which have the actual user language information - does it
> really make sense to add language information to IP databases?


That's a valid concern.

What we are seeing is that the adoption of geoip filtering and classification is increasing for a variety of services, not restricted to those delivered through a web browser. Some of these are using the country attribute of the RIPE DB as a source of information and from that attribute they make an assumption on the language. I see this as an escalating problem.

I don't believe that the language attribute will be a magic bullet, but as a generic non-protocol dependent means of publishing language preferences it could be a sensible option for those who are looking at the RIPE DB today. It could be an addition to the toolbox that is available for mitigation further problems in this area.

Cheers,

-- Janne

-- 
#: ------------- Ålcom ------------- Network Operations Center ---------
#: Jan-Erik Eriksson		mailto: jee at alcom.ax
#: Ålcom			phone: +358 18 525923
#: Servicegatan 12		fax: +358 18 14643
#: AX-22100 Mariehamn		URL: http://www.alcom.ax

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20130321/ed2132f5/attachment.sig>