Thursday, October 30th, 2008

Language JSONP Service

Category: JSON

<p>Ben Lisbakken, an ex-colleague from Google and all round good guy, has created a simple JSONP service (in the vein of json-time and html-whitelist) that calculates the users language based on browser headers:

http://langdetect.appspot.com/?callback=setLanguage

This will return something like:

setLanguage({“languages”: ['en-us', 'en']});

Ben created a nice little sample that shows you content in the language you desire using the AJAX Language API.

Related Content:

Posted by Dion Almaer at 1:19 am
7 Comments

+++--
3.6 rating from 18 votes

7 Comments »

Comments feed TrackBack URI

There’s been a discussion in the WHATWG about adding the XMLHttpRequest interface to the HTMLDocument.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016922.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016948.html

What follows is something I just posted there in response to this post:

[The Language JSONP Service] seems like a terrible workaround since the Accept-Language header is sent from the same browser that the script is running in; a script shouldn’t have to make an HTTP request just to find out what the browser’s request headers are.

Therefore, I propose that in addition to implementing on HTMLDocument the XMLHttpRequest interface subset I initially suggested, I see that it would also be very useful for a script to obtain the request headers that were sent which resulted in the current document as the response. The current version of XMLHttpRequest hints to a future version including a getRequestHeader() method, a method which would complement getResponseHeader(); there could also be a getAllRequestHeaders() method that would correspond to the existing getAllResponseHeaders() method. (Obviously it would not make sense to implement the setRequestHeader() method.)

If these two methods ( getRequestHeader() and getAllRequestHeaders() ) were implemented, then there would be no need for a “Language JSONP Service” because there would be a better way to get the same result synchronously without any HTTP request, for example: document.getRequestHeader(‘Accept-Language’)

Comment by westonruter — October 30, 2008

I feel I should clarify: by “terrible” I don’t mean to say that this app isn’t clever; it is very useful. But its existence highlights a deficiency in the state of scripting in the browser.

Comment by westonruter — October 30, 2008

For the record, I just posted an idea on how to use it with GWT to automatically choose the appropriate locale for your application:
http://groups.google.fr/group/Google-Web-Toolkit/msg/e8ca2612aa72cfed
Maybe someone could test it and report how well/bad it actually works ;-)

Comment by tbroyer — October 30, 2008

I’m mulling over an OSS project to provide a Google Apps API that identifies the language of some sample text, or the text of the page on a given URI.

If anyone would particularly like to see that drop me a comment here or on my blog. It’d be nice to have help but isn’t too big a project alone either.

The techniques involved are pretty well understood:
http://richmarr.wordpress.com/2008/09/30/language-detection-using-trigrams/

It’s also a cut-n-paste problem in the Java world, but it’d be nice to have a funky open API on Appspot:
http://richmarr.wordpress.com/2008/10/24/creating-a-language-detection-api-in-30-minutes/

Comment by itchyrich — October 30, 2008

Doesn’t this accomplish the same thing without an HTTP request:
var language = navigator.language || navigator.userLanguage;
Is there a difference?

Comment by kriszyp — October 30, 2008

@westonruter
I couldn’t agree more. I created it because of the complete deficiency in client-side language detection which should be functional.

@kriszyp
There are a few properties that can tell you the language in the navigator object. I did a lot of testing and couldn’t find a way to rely on them cross-browser. Go try it out and you’ll see that when you change your language, your navigator.language || navigator.userLanguage || navigator.systemLanguage || navigator.userAgent || navigator.browserLanguage don’t necessarily change. Maybe someone has a good client side technique for this, but I did some quick browsing through Dojo & jQuery and didn’t find any client side browser language detect (correct me if I’m wrong).

Comment by lisbakke — October 30, 2008

@westonruter
BTW, before creating this API I was digging around for hacks to find the language and one of the things I was hoping for was exactly what you said:
getRequestHeader() / getAllRequestHeaders()

Comment by lisbakke — October 30, 2008

Leave a comment

You must be logged in to post a comment.