Caution: The documentation you are viewing is
for an older version of Zend Framework.
You can find the documentation of the current version at docs.zendframework.com
Increasingly, developers need to tailor their content for multiple
languages and regions.
Zend_Form aims to make such a task trivial, and
leverages functionality in both Zend_Translate and Zend_Validate to do so.
By default, no internationalisation (I18n) is performed. To turn on I18n
Zend_Form, you will need to instantiate a
Zend_Translate object with an appropriate adapter, and
attach it to
See the Zend_Translate
documentation for more information on creating the translate
object and translation files
|Translation Can Be Turned Off Per Item|
You can disable translation for any form, element, display group, or
sub form by calling its
In order to initialize I18n in forms, you will need either a
Zend_Translate object or a
Zend_Translate_Adapter object, as detailed in the
Zend_Translate documentation. Once you have a
translation object, you have several options:
Easiest: add it to the registry. All I18n aware components of Zend Framework will autodiscover a translate object that is in the registry under the 'Zend_Translate' key and use it to perform translation and/or localization:
// use the 'Zend_Translate' key; $translate is a Zend_Translate object: Zend_Registry::set('Zend_Translate', $translate);
This will be picked up by
If all you are worried about is translating validation error
messages, you can register the translation object with
// Tell all validation classes to use a specific translate adapter: Zend_Validate_Abstract::setDefaultTranslator($translate);
Alternatively, you can attach to the
object as a global translator. This has the side effect of also
translating validation error messages:
// Tell all form classes to use a specific translate adapter, as well // as use this adapter to translate validation error messages: Zend_Form::setDefaultTranslator($translate);
Finally, you can attach a translator to a specific form instance
or to specific elements using their
// Tell *this* form instance to use a specific translate adapter; it // will also be used to translate validation error messages for all // elements: $form->setTranslator($translate); // Tell *this* element to use a specific translate adapter; it will // also be used to translate validation error messages for this // particular element: $element->setTranslator($translate);
Now that you've attached a translation object to, what exactly can you translate by default?
Validation error messages. Validation
error messages may be translated. To do so, use the various
error code constants from the
validation classes as the message IDs. For more information
on these codes, see the Zend_Validate
Alternately, as of 1.6.0, you may provide translation strings using the actual error messages as message identifiers. This is the preferred use case for 1.6.0 and up, as we will be deprecating translation of message keys in future releases.
Labels. Element labels will be translated, if a translation exists.
Fieldset Legends. Display groups and sub forms render in fieldsets by default. The Fieldset decorator attempts to translate the legend before rendering the fieldset.
Form and Element Descriptions. All form types (element, form, display group, sub form) allow specifying an optional item description. The Description decorator can be used to render this, and by default will take the value and attempt to translate it.
Multi-option Values. for the various
items inheriting from
(including the MultiCheckbox, Multiselect, and Radio
elements), the option values (not keys) will be translated
if a translation is available; this means that the option
labels presented to the user will be translated.
Submit and Button Labels. The various Submit and Button elements (Button, Submit, and Reset) will translate the label displayed to the user.