|
heh… ZF…
The default behavior is to inspect the browser’s headers and determine a locale from the ‘Accept-Language’ HTTP header. Most spiders don’t bother sending this header as it is optional. ZF requires it by default, when it’s not found, they feel that it’s good to throw an exception. Magento doesn’t catch this exception, and thus you see the error on the screen.
The issue has already been fixed. It’s fixed in Magento 0.7 latest, I think it’s fixed in the latest release of ZF, not positive.
The core part of the issue is in the raw PHP function setlocale(). You can use it to “get” the current locale setting. The only problem is if your apache has been launched from an environment where the locale variables are already set, LC_ALL, LC_CTYPE, whatever, then setlocale() returns a different format. Normally it returns a list of key value pairs that you can split like:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;
But, if your environment has already set the LC_ALL, then setlocale() returns only the letter “C”, meaning that you can’t parse it up normally and get all the different variable settings.
So, php is goofy (we all know that), ZF is goofy (because it doesn’t know that PHP is goofy and because it throws an exception if “auto-detection” fails) and magento is goofy because it doesn’t catch the Exception thrown by ZF (but Mage is still beta).
If your system has an “old” ZF, maybe Mage is picking up that first before its own copy… Anyways, here’s the fix*:
Add this between lines 198 and 199 of lib/Zend/Locale.php (end of function getDefault())
if (!array_key_exists(self::$_Default, $languages)) {
$languages[self::$_Default] = 0.1;
}
Again, this is fixed on my install of 0.7 already.
(* i don’t really consider this a fix because it doesn’t apply any locale if you haven’t set a default one, it merely shoves an empty array key at the end of “languages”.
|
