ZF-9619: Custom Translate Adapters don't work in 1.10.3
Description
After revision 21661, custom Translate Adapters are not being executed. Instead, a notice like: Notice: The language 'en' has to be added before it can be used. in /Path/to/library/Zend/Translate/Adapter.php on line 394 is displayed. Reverting changes from the revision fixes the bug, and has the Adapter working as before.
Comments
Posted by Thomas Weidner (thomas) on 2010-04-06T11:04:03.000+0000
Sorry, "but do not work" is not enough for reproduction. What are you doing, what are you calling, how does your adapter look like.
Note: Language notices can be switched off... they are no failure, they are wished and available since 1.8 or earlier.
Posted by Dan Osipov (danospv) on 2010-04-06T11:23:00.000+0000
Notice is not an issue in itself, but the Adapter is not executed. Here is the Adapter: <?php class MyNamespace_Adapter extends Zend_Translate_Adapter { private $_data = array();
}
I call it using: $translator = new Zend_Translate('MyNamespace_Adapter', '', 'en');
I was able to narrow down the issue to the following lines in Zend/Translate/Adapter.php:
At the end of these lines, the locale is set to 'auto', but:
$this->setLocale() is executed, even though there is no translation data was loaded from the Adapter yet.
Let me know if this helps
Posted by Thomas Weidner (thomas) on 2010-04-06T12:16:52.000+0000
I can not verify your problems:
You are giving '' as content, so there are no data which are added. The raised notices are therefor correct.
When I change your call to give content like
and add a var_dump within your _loadTranslation method, this var_dump returns the previous given "somecontent".
Posted by Dan Osipov (danospv) on 2010-04-07T01:45:05.000+0000
Ok, I see. This works because of the following:
But why is the content required now? This was not the case in 1.10.2, and I understand that 1.10.3 was a bugfix release, that shouldn't have changed functionality?
Posted by Thomas Weidner (thomas) on 2010-04-07T12:58:26.000+0000
A translation was also required before.
$data was not allowed to be empty... we just added array handling which means that the old $data is now internally named $options['content'].
Posted by Thomas Weidner (thomas) on 2010-04-07T12:58:44.000+0000
Closing as non-issue