I'm sorry to say it, but your language detection script has a number of problems (all PHP scripts for this purpose, that I have found, except the PEAR package, suffers from these or other problems):

1. It ignores quality values (q=0.2). Not the worst offense in the context of an Accept-Language header, but easy enough to implement.
   
2. It doesn't allow for a distinction between "en-gb" and "en-us" as it will always reduce them to "en".
   
3. Given this Accept-Language header: "da, en-us;q=0.8, en;q=0.5, fr;q=0.3" (straight from my browser) and this redirect list: "fr, en, default", it will select "default", despite both languages being in both lists, as it will try to match "da".
   

Here are the relevant RFCs:
www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9
Back to top

I took a look, the code did have a small bug, related to the presence of a space in the language string.
Back to top

I pasted in the value you gave above to test it, and here's the output:



then I ran a test page:



As you can see, there is a bug

I haven't looked at that script for a while though, so it's nice to see that it's still working more or less

I'll take a look at that one and see if I can get it fixed.
Back to top

1. is fairly minor, although it should at the very least handle "q=0" properly.


Whoops, my bad. It's actually been a little while since I tested it, and missed that when skimming the code today. Not that it matters much, since $feature='data' doesn't do much useful. It would be better to fix the 'header' part and then match the output against the language list.


3. is hardly a fringe case, but a serious design flaw that is easily solved with a few array_intersect() and array_diff().
Don't you agree that if your site offers, say, a French version and my browser asks for it but gets the English version, that it's a problem? Sure you can (and should) have a manual switch, but what's the point in having a script do it automatically, if it doesn't work?


Fixing it would essentially be the same as a rewrite, so why bother?

Actually I had already started on my own implementation before I found yours, but figured that there ought to be some finished scripts out there. Well, there are a few, but as I said they all (except for the PEAR package which, however, does complete content negotiation) suck in various ways, and are obviously written by complete novices or someone that really shouldn't be allowed to program.
My implementation: www.anaerob.dk/stuff/GetPreferredLanguage.php.txt
It still needs some polish/testing, and I'm sure the code could use some optimising/refactoring, but the general functionality is in place and seems to work as expected.
Back to top

sorry, I updated my postings.

The only problem with the script was failing to remove whitespaces in the initial string, which was an oversight easily patched.

the test version now works as expected.

Re trying to guess what the user actually wants to happen on a site with language redirects, with multiple languages, that's not something I think you'll find much use for.

Certainly very few major sites chose this course of action.

I wouldn't presume to do that, although I might offer the first language option as default, but that's about all I'd do.

You spent a lot of extra effort though, all that was happening here was failing to remove white space from strings, and then after that, all you needed to do was add another array item to put in the q value, if you wanted to do that, which I can see no reason to do.
Back to top

The actual bug was trivial to fix, though it did take a while to figure out:

All that is required is to replace ' ' with '', null:


This fix is in 0.3.5 now.

As for the q stuff, that's also fairly trivial to add, but also pretty pointless, but in case someone wants it, just add, with a q is present test,


there, use: $temp_array[2] = explode( '=', explode(';', $language_list) );

or something like that, and test if you want more data, but again, using q for assigning pages is probably just going to bug your users.

Anyway, thanks for the bug report, even though the report wasn't really accurate, there was in fact a bug, which did cause some issues for multiple languages, so best to have it work right.
Back to top