Browser Language Codes fail to match
Posted: Tue Apr 14, 2015 8:06 pm
The default language codes for English which are inserted on DB creation do not appear to follow web standards, and therefore will not find a match in many cases.
Case:
As of OpenCart 2.0.2.0 the database sets the following string for the English language locale:
This is exploded into an array and used to match against an array of preferred languages sent by the browser and held in the global variable $_SERVER['HTTP_ACCEPT_LANGUAGE']. In my case using Firefox v37 on OS X that string happens to be "en-US,en;q=0.5". Exploded this produces the array:
You can see the first element of the array follows standards described here: http://www.metamodpro.com/browser-language-codes setting the default language to "en-US'. The alternate would be 'en'.
In the first case it will not match our array since OpenCart uses '_' (underscore) but browser transmits '-' (dash) as separator. In the second it could match but for the relative quality factor string following en. So in either case we will not find a match.
Additionally, some browsers add space in the string so that exploded array elements could end up as ' en-US' which will also fail to match anything unless the additional whitespace is trimmed.
My suggestion would be add or amend the locale field to include 'en-US' and 'en' and also revise index.php to format the $browser_languages array. We should remove the relative quality factor string and trim whitespace - maybe like so:
Another solution would involve rewriting the language detection portion to use php's http_negotiate_language() function.
Case:
As of OpenCart 2.0.2.0 the database sets the following string for the English language locale:
Code: Select all
en_US.UTF-8,en_US,en-gb,englishCode: Select all
array(
[0] => 'en-US'
[1] => 'en;q=0.5'
)In the first case it will not match our array since OpenCart uses '_' (underscore) but browser transmits '-' (dash) as separator. In the second it could match but for the relative quality factor string following en. So in either case we will not find a match.
Additionally, some browsers add space in the string so that exploded array elements could end up as ' en-US' which will also fail to match anything unless the additional whitespace is trimmed.
My suggestion would be add or amend the locale field to include 'en-US' and 'en' and also revise index.php to format the $browser_languages array. We should remove the relative quality factor string and trim whitespace - maybe like so:
Code: Select all
$browser_languages = preg_replace(array('/;.*/','/\s/'),'',$browser_languages);