On Wednesday 12 November 2003 06:40 am, S wrote:
| Ian,
|
| That's it! The following script:
|
| <?php
| echo $_SERVER[HTTP_ACCEPT_LANGUAGE];
| ?>
|
| ..generates the following output using Safari:
|
| en-us, ja;q=0.21, de-de;q=0.86, de;q=0.79, fr-fr;q=0.71, fr;q=0.64,
| nl-nl;q=0.57, nl;q=0.50, it-it;q=0.43, it;q=0.36, ja-jp;q=0.29,
| en;q=0.93, es-es;q=0.14, es;q=0.07
|
| ..and the following output using Windows IE 6.0.2800.1106:
|
| en-us
|
| I don't understand why Safari presents itself as supporting so many
| languages. However, the match on 'ja' is clearly what's causing the
| redirect. It's a positive match for stristr.
|
| As a PHP coder by profession, I would suggest testing for the presence
| of 'ja' in $_SERVER[HTTP_ACCEPT_LANGUAGE] and the absence of 'macintosh'
| (!eregi('macintosh')) in $_SERVER[HTTP_USER_AGENT].
I would suggest instead changing the test to a check for supporting 'ja' and
*not* supporting 'en'. That way if some other browser says that it can
support a variety of languages, it would work right by default as well. Eg,
if (stristr($_SERVER["HTTP_ACCEPT_LANGUAGE"], "ja") &&
!stristr($_SERVER["HTTP_ACCEPT_LANGUAGE"], "en")) {
header("Location: http://de-co.info/freenet/";);
exit();
}
I mean, that's the gist of the problem - that the code assumes that "japanese"
means "not English" when it doesn't necessarily.
I agree it's odd that this happens for the Safari since Konqueror itself does
not do this. Then again it does seem logical for a "lanuage accept field" to
tell the languages the browser accepts. But most browers seem to use it more
as a lanuage "preference" field, and the code here assumes that's what it is.
| Of course, I imagine you have a number of other tests taking place which
| will complicate things a bit. In any case, it's the test for 'ja' that's
| causing Safari to head to the Japanese page.
|
| Thanks!
|
| -s
_______________________________________________
Support mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
