Application wide locale in Zend Framework
Hy interested ones,
a new feature has been added within Zend Framework. it now supports the usage of an application wide locale. Anyone who is using I18N classes in his application will love this feature.
So what’s all about this new feature…. let’s look into details. Until Zend Framework 1.5 when you wanted to use several I18N aware classes you had to set the locale you wanted to use within all classes. This looked like this:
$locale = new Zend_Locale('en_US');
$date1 = new Zend_Date($locale);
$date2 = new Zend_Date($locale);
$currency = new Zend_Currency($locale);
When you use only one or two instances there is not much difference. But the more instances you use the more work you would have with the syntax. Looking at this in detail I thought why not simply set the locale once within your bootstrap and let the framework do the rest.
The solution was the usage of the registry. So let’s look at the same example and the difference in the usage:
$locale = new Zend_Locale('en_US');
Zend_Registry::set('Zend_Locale', $locale);
...
$date1 = new Zend_Date();
$date2 = new Zend_Date();
$currency = new Zend_Currency();
As you can notice now, you can forget about the locale as it’s automatically taken from the registry. This is a small and simple solution but it will solve you several headache. You can use this feature within the actual trunk or you have to wait until 1.7 is released.
Have fun with it, anyway.
Greetings,
Thomas Weidner, I18N Team Leader, Zend Framework
15 comments on Application wide locale in Zend Framework
Hugo on Tuesday, 29 July 2008 at 15:45:18 says:
Nice feature. Thanks for this new tips, which will ease one more time the developper’s work.
Jaka Jancar on Monday, 4 August 2008 at 15:51:20 says:
When is GA or RC2 (if that will already include this) expected?
thomasw on Monday, 4 August 2008 at 16:54:47 says:
RC2 is announced for this week… I expect GA until end of next week.
Jaka Jancar on Friday, 8 August 2008 at 13:50:05 says:
I have a concern about this feature:
If you use the date validator (for example with forms) and do not explicitly specify a locale, it validates the date for the ISO format (YYYY-MM-DD).
Will this global locale instance also start affecting validators without explicitly set locale, and start validating human-readable dates too?
I hope not.
thomasw on Friday, 8 August 2008 at 14:02:08 says:
Why should it not validate ?
The date validator uses a fixed string comparison… there is no I18N class or locale needed in this process.
EXCEPT You define a localized format yourself.
A class which does not use I18N is not affected by this feature.
Btw: YYYY-MM-DD is no ISO format. This would be yyyy-MM-dd. ;-)
Jaka Jancar on Friday, 8 August 2008 at 16:52:11 says:
Oops, you’re right. I thought that Zend_Validate_Date always just proxies to Zend_Date::isDate(), but now I see it only does that if locale/format is specified. All is well then :)
Regarding the ISO format, I was just quoting the manual _AND_ the api docs :P
Since you’re the ZF i18n guy and you’re answering so promply, I hope you don’t mind if I ask you another question :)
I’m internationalizing my app by calling $translator->translate(’blah’) in my views and some actions. I then plan on using poEdit to create translations similarly to this tutorial:
http://www.tornstrand.com/2008/03/29/string-localization-with-gettext-and-zend-framework/
I see two problems with this:
1) There might be other objects with the translate() function which don’t serve i18n, and calls would get picked up when they shouldn’t.
So far I think the safest way would be to define a global function, and then there could be no doubt about what it serves.
This is more theoretical than not, but I’m still curious: is there’s a good practice for avoiding this?
2) This one is more practical: the validator messages won’t get picked up this way, since they’re used through templates.
Is there a smarter way to fix this than to override all the used validators and do something like the following in their constructors:
$this->_messageTemplates = array(
self::NOT_YYYY_MM_DD => $translator->translate(”‘%value%’ is not of the format YYYY-MM-DD”),
…
);
And then disabling translation, to avoid translating it twice.
Thanks!
thomasw on Friday, 8 August 2008 at 21:20:34 says:
Comments should be related to the topic and not ask questions which are not related to what was written here. So please ask in the mailinglist of ZF. I dont want to bother others with a long unrelated comment history. ;-)
Thank you…
thomasw on Friday, 8 August 2008 at 21:30:55 says:
In the meantime:
1) try the translation view helper
2) Use message overriding
3) Ask in fw-general@lists.zend.com
Greetings
Peter on Friday, 29 August 2008 at 14:12:48 says:
Will it be in the 1.6.0 release? It seems that it isn’t already in 1.6.0RC3…
thomasw on Friday, 29 August 2008 at 16:46:26 says:
No, Zend has decided to delay this and other new I18N features until 1.7. But you can use the actual SVN trunk where this feature was already implemented.
Mike on Thursday, 4 September 2008 at 16:43:32 says:
This is a useful feature, but why use the registry? Wouldn’t it make more sense to use a static member variable in Zend_Locale, as setDefault() does? And shouldn’t Zend_Locale provide a static method like setApplicationLocale() (or whatever) to set this, rather than requiring the developer to store the value in the registry themselves?
thomasw on Thursday, 4 September 2008 at 17:03:48 says:
I think you don’t get the clue of this feature. The thing is not to set a “Default” locale, this was already allowed before. The thing is that you can use what-ever locale you are using for all components without giving it as parameter. This includes for example also browser, environment or even manually set locales.
And as it’s stored in Zend_Registry (not the registry) you are also able to use your own implementation or subclass, as long as it has the same key-name.
This is common practice in several components within the framework.
So it would not make sense to have multiple ways for the same purpose implemented.
Mike on Friday, 5 September 2008 at 01:53:25 says:
Surely that *is* setting a default? Zend_Locale already provides a setDefault() method, but to me that’s setting a “fallback” locale rather than a default.
In other components where a similar practice is used (namely Validate and Form) the default object instance is stored in a static variable. Only if this is null does the getDefault method look in the registry. And whether the default is stored in the registry or a static variable, it doesn’t make any difference to whether or not you can use your own subclasses.
thomasw on Friday, 5 September 2008 at 02:17:40 says:
No it’s not.
One thing is what the component itself does. It provides a default for the framework which is used only by Zend_Locale. It’s completly independend from other components. This was supported in the past.
The other thing, and this is what is described in this article, is that all I18N components know where to search for Zend_Locale themself.
Also the old default behaviour is no longer supported. It was instead changed to a framework wide locale which works slightly differently than before.
This was the reason why the dev-team decided to delay the integration until 1.7.
Related to subclass… Zend_Date would never know itself that it should use My_Locale which extends Zend_Locale instead of Zend_Locale itself. This can not work the way you described it.
What Zend_Framework provides is only a proove of concept and a sort of best practice. So, when the new implementation does not fit your needs, feel free to make your own extension.
Mike on Friday, 5 September 2008 at 12:58:21 says:
Why won’t it work? All I’m saying is store the default object in a static variable rather than in the registry.
$locale = new My_Subclassed_Locale(’en_US’);
Zend_Locale::setApplicationWideLocale($locale);
…
setApplicationWideLocale($locale)
{
self::$_applicationWideLocale = $locale;
}
…
$localeIShouldBeUsing = Zend_Locale::getApplicationWideLocale();