The model component can vary dramatically in responsibilities and data store from one MVC application to the next. The ZF community has not defined a model interface, class, or other formalism simply because we wanted to avoid introducing limitations without significant added value.
Simple answer: both. Zend Framework provides all the components required for most web applications in a single distribution. But Zend Framework components are also loosely coupled, making it easy to use just a few components in a web application- even alongside other frameworks! Using this use-at-will architecture, we are implementing features commonly found in more monolithic frameworks. In fact, we are currently working on a tooling component for the 1.8 release that will make it simpler to build applications using ZF components, yet will not sacrifice the use-at-will nature of existing ZF components. It's a testament to the use-at-will architecture of Zend Framework that the tooling component itself can be used standalone.
A variety of components are translation aware (i.e., accept Zend_Translate objects), including:
To have them all use the same Zend_Translate instance, simply place it in the registry with the key "Zend_Translate":
With ZF 1.7 an application wide locale is supported. You can do the following in your bootstrap file:
$locale = new Zend_Locale('en');
From now on, all locale aware components will use your locale object stored in the registry as long as you don't give another one manually.
When using own formats in your code you could come to a situation where you get for example 29.12.2009, but you expected to get 29.12.2008.
There is one year difference: 2009 instead of 2008. You should use the lower cased year constant. See this example:
Note the lower cased "y" which makes the difference and outputs the real year.