Issues

ZF-8435: Zend_Application_Resource_Locale uses default locale instead of auto-discovery

Description

For instance, the getLocale() function should be modified similar to this:
public function getLocale()
{
// Zend version incorrectly ignores HTTP_ACCEPT_LANGUAGE value when create locale object
if (null === $this->_locale) {
$options = $this->getOptions();
if (isset($options['default'])) { // Set the fall-back locale Zend_Locale::setDefault($options['default']); } else { // Should the web server's locale be set as a default when none provided? }
// Now create the locale with automatic locale discovery enabled (the default method)
$this->_locale = new Zend_Locale();

$key = (isset($options['registry_key']) && !is_numeric($options['registry_key']))
? $options['registry_key']
: self::DEFAULT_REGISTRY_KEY;
Zend_Registry::set($key, $this->_locale);
}
return $this->_locale;
}

Comments

When the application.ini file sets a default (fall-back) locale, Zend_Application_Resource_Locale incorrectly creates the locale object with it. This default should be set before creating the locale object and then create the object using automatic locale discovery.

For instance, the getLocale() function should be modified similar to this: public function getLocale() { // Zend version incorrectly ignores HTTP_ACCEPT_LANGUAGE value when create locale object if (null === $this->_locale) { $options = $this->getOptions(); if (isset($options['default'])) { // Set the fall-back locale Zend_Locale::setDefault($options['default']); } else { // Should the web server's locale be set as a default when none provided? } // Now create the locale with automatic locale discovery enabled (the default method) $this->_locale = new Zend_Locale();

$key = (isset($options['registry_key']) && !is_numeric($options['registry_key']))
? $options['registry_key']
self::DEFAULT_REGISTRY_KEY; Zend_Registry::set($key, $this->_locale); } return $this->_locale; }

I edited the issue itself a bit, so that the issue itself makes immediately clear what the supposed problem would be, please check if I summarized and interpreted your problem correctly.

  • You marked the issue with affects version with 1.8.x, does it still occur with 1.9.6 (and/or trunk)?
  • Could you please add some code, give its output, and give its expected output.

Here is some code notes:

[configs/application.ini] resources.locale.default = en_US

[index/index.phtml] <?php echo '
HTTP_ACCEPT_LANGUAGE: ' . Zend_Controller_Front::getInstance()->getRequest()->getServer('HTTP_ACCEPT_LANGUAGE'); $locale = Zend_Registry::get('Zend_Locale'); $defaultLocale = $locale->getDefault(); foreach ($defaultLocale as $key => $value) { echo '
Default locale: ' . $key . ' (' . $value. ')'; } echo '
Language: ' . $locale->getLanguage(); echo '
Region: ' . $locale->getRegion(); ?>

[output with Zend version of Locale resource's getLocale()] HTTP_ACCEPT_LANGUAGE: de-de,en-us;q=0.7,en;q=0.3 Default locale: en_US (1) Language: en Region: US

(Notice that even though the preferred language in HTTP_ACCEPT_LANGUAGE is "de-DE", the language set in the Locale is "en_US". This is because the existing Locale resource sets the locale language to the default setting, instead of allowing it to detect the language using Zend_Locale automatic locale discovery)

[output using getLocale() based on code in the above comment] HTTP_ACCEPT_LANGUAGE: de-de,en-us;q=0.7,en;q=0.3 Default locale: en_US (1) Language: de Region: DE

(Notice that the Locale created by the modified Locale resource is correctly set to "de_DE" because the locale is being created using automatic locale discovery. Automatic locale discovery ($locale = new Zend_Locale();) will detect the locale by first looking at HTTP_ACCEPT_LANGUAGE. If automatic discovery fails, it will ultimately use the locale default.)

Also, this problem exists in the current (1.9.4) release.

Ignore the previous comment. It is a problem in the current release (1.9.6)

I just checkout the SVN trunk code. The problem exists in trunk.

Note: this is a problem with Zend_Application_Resource_Locale::getLocale().

Should be fixed now, thank you for reporting. If you still encounter this issue, please reopen it (and add a comment).