Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_View_Helper_Translate Component Proposal

Proposed Component Name Zend_View_Helper_Translate
Developer Notes
Proposers thomas
Revision 2.0 - 13 January 2008: Finished implementation
1.1 - 3 November 2007: Small adoptions
1.0 - 1 November 2007: Initial revision (wiki revision: 9)

Table of Contents

1. Overview

Zend_View_Helper_Translate is an view helper for having easy and simple integration of Zend_Translate within the view.

2. References

  • [Zend_Translate]

3. Component Requirements, Constraints, and Acceptance Criteria

Requires a Zend_Translate instance to operate. It will add the possibility for users to translate messages from within the view without much coding.

4. Dependencies on Other Framework Components

  • Zend_Translate

5. Theory of Operation

Translates messages through Zend_Translate. Can accept parameters to be integrated.

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: [DONE] Class integration
  • Milestone 3: [DONE] Unit tests
  • Milestone 4: [DONE] Documentation

7. Class Index

  • Zend_View_Helper_Translate

8. Use Cases


// simple translation from within the view
$this->translate('Translate this');


// translation with one parameter from within the view
$this->translate('Translate this %1\$s', 'again');


// translation with multiple parameters from within the view
$this->translate('Translate this %1\$s with %2\$s and %3\$s %4%s', 'again', 'one', 'another', 10);


// translation with multiple parameters from within the view
$this->translate('Translate this %1\$s with %2\$s and %3\$s %4%s', array('again', 'one', 'another', 10));

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 02, 2007

    <p>Thomas – I'd have Zend_View_Helper__ extend Zend_View_Helper_Translate, or vice versa, and have the helper method simply call the appropriate parent method:</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    class Zend_View_Helper__ extends Zend_View_Helper_Translate
    public function _($messageid)

    Unknown macro: { return $this->translate($messageid); }

    <p>Otherwise, straightforward and simple addition that will add some nice i18n capabilities to view scripts.</p>

    1. Nov 03, 2007

      <p>Of course... I would not have doubled the code... just thought not to implement the class before it's accepted. <ac:emoticon ac:name="wink" /></p>

      1. Jan 02, 2008

        <p>Actually, Zend_View_Helper__ is an invalid class name; Zend_Loader::loadClass() replaces all underscores with directory separators, so this will quite simply not work for technological reasons. Additionally, it would be confusing to have two helpers with identical functionality; let's leave it as simply Zend_View_Helper_Translate, which leaves us with the $this->translate() syntax, which is clean and transparent in functionality.</p>

  2. Nov 03, 2007

    <p>A few things which need to be discussed:</p>

    <li>Initiation:<br />
    Which is the best method to get the instance of Zend_Translate within the view script...<br />
    Registry ?<br />
    DeclareVars ?<br />

    <li>Language:<br />
    How to change the actual language within the view ?<br />
    Zend_Translate itself accepts an additional parameter <strong>locale</strong> which changes the actual language within the actual translation...<br />
    Function ?<br />
    Not at all ?<br />

    1. Nov 12, 2007

      <p>Initiation:<br />
      Maybe in constructor, so if its not set before used the first time, nothing will happen than just returning the incoming string? But this will cause the helper to be instantiated every request even if its not used. Maybe it could be nice, if the View can take some options for the case that a helper is instantiated.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[$view->setHelperOptions ('helperName', array('someOption', 'someValue');]]></ac:plain-text-body></ac:macro>
      <p>I dont like Registry to give a value to something else as it seems quite dirty to me <ac:emoticon ac:name="wink" /></p>

      <p>Language:<br />
      I dont know, how to realize, but it would be nice, if the designer get the possibility to translate something like "this page in language xy" into the language xy. I dont think, that a Locale-object will be useful as it has nothing to do in the view, but a string can be a parameter to be replaced in the string also. So i currently dont see another way than adding a new method, which changes the language. Maybe it would be useful to change this language only one to</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[$this->_('translate to xy');
      $this->useLanguage('ab')->_('translate to ab');
      $this->_('translate to xy again');]]></ac:plain-text-body></ac:macro>

    2. Jan 02, 2008

      <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[The way we approached this with the various Zend_View Enhanced helpers is to overload the helper slightly: passing no arguments to the helper returns the helper object itself – which then allows you to create accessors for such things as setting the Zend_Translate object and language:

      This would allow the user to set helper status from a plugin, a controller, or a variety of other places.

      As a fallback, you could default to pulling from some default Zend_Registry keys; if done this way, use the class name as the key:

      if (!Zend_Registry::isRegistered('Zend_Translate'))

      Unknown macro: { throw new Zend_Translate_Exception('No Zend_Translate object available!'); }


      (You could use 'Zend_Translate_Locale' as the key for the current locale, or simply use the currently registered locale in the Zend_Translate object.)

      Since this paradigm of no arguments == returning helper is used throughout the Zend_View Enhanced helpers, as well as other new helpers, this is the recommended pattern to follow with Zend_View_Helper_Translate; the registry fallback is only a suggestion.

  3. Nov 06, 2007

    <p>About Initialization, I use a static method.</p>
    <ac:macro ac:name="code" />
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    public static function setTranslator(Zend_Translate $translate)

    Unknown macro: {     self}

    <p>for the name of the helper :</p>

    <p>It can be usefull, to have $this->_() or $this->tr(), maybe it can be compatible with xgettext or lupdate(QT, XLIFF) for extracting translation.<br />

    1. Nov 06, 2007

      <p>Using a static initialization means that you can use only one instance of Zend_Translate per application. This would not be the preferred method in my eyes.</p>

      <p>And related to methodnames... if you read the proposal you will see that "_()" is supported because it's also supported by Zend_Translate.<br />
      As "tr()" is not supported by Zend_Translate we will not add this one to the helper. It would be useless to add 3 or more methods which all do the same.</p>

  4. Dec 25, 2007

    <p>That's a cool idea... Must have!</p>

  5. Jan 02, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">"Zend Comments"</ac:parameter><ac:rich-text-body>
    <p>This component is approved for incubator development, with the following<br />

    <li>The short '_' version will not be available (due to technological reasons) and should not be implemented.</li>
    <li>The helper should return itself if no arguments are passed to it, allowing the user to then call on accessors to set the Zend_Translate object and/or current locale.</li>
    <li>The helper <strong>could</strong> default to using Zend_Registry if no Zend_Translate object is registered with it (but this is not a requirement).</li>