ZF-1096: Add autoechoing function

Description

For simplication we could add a auto-print function...


    public function print($messageId, $locale = null, array $parameters)
    {
        sprintf ($this->_adapter->translate($messageId, $locale), $parameters);
    }

So a user would have a simplification of it's view:


// old
print $translate->translate('mystring', $locale);
sprintf( $translate->translate('mystring', $locale), $firstparam, $secondparam, $thirdparam);

// new
$translate->print('mystring', $locale);
$translate->print('mystring', $locale, $parameters);

Less code to write for the user and simplification as also much more readability. Ideas, Thoughts, to implement until which version ??

Comments

I don't think print() should be added to translate functionality.

Zend_Translate knows nothing about output method we use in our application. It may be HTML/WML/XML/plain text/... It also may be View part of MVC paradigm offered by in ZF.

I don't think we have to distinguish this one output method.

From the other side userland code simplification is important goal for the framework. Such simplification may be also done in userland and it may be a good example for Zend_Translate documentation ("How to use" example):


class OutputGenerator {
    /**
     * Translate object
     *
     * @var Zend_Translate
     */
    private $_translate;
    
    /**
     * Translate object
     *
     * @param Zend_Translate $translate
     */
    public function __construct(Zend_Translate $translate)
    {
        $this->_translate = $translate;
    }
    
    /**
     * Print translated message
     *
     * @param string $messageId
     * @param string|Zend_Locale $locale
     */
    public function tprint($messageId, $locale = null)
    {
        print $this->_translate->translate($messageId, $locale);
    }

    ...
}

...

$ug = new OutputGenerator($translator);

...

$ug->tprint($msg);
<?php $translate->print('My translated string', $locale); ?>

{quote} But this is no problem... Zend_Translate only prints the translated string. And within the translated content there is never a html / xml or whatever tag. {quote} Zend_Translate can not just print the translated string as it may need to be escaped first (again think about html rendering of the string "my stuff > your stuff"). You have to allow the user to decide how to ouput the string... so I think a solution would be something like this:


class Zend_Translate
{
    /**
     * The callback to use when displaying a string
     *
     * @var $_output_callback
     */
    private $_output_callback = 'echo';

    /**
     * Define the callback to use when displaying a string
     *
     * @param  callback $callback
     * @throws Zend_Translate_Exception
     */
    public function setOutput($callback)
    {
        if (!is_callable($callback)) {
            throw new Zend_Translate_Exception('a valid callback is expected');
        }

        $this->_output_callback = $callback;
    }

    /**
     * Translate a string and display it
     *
     * @param  string              $messageId  Original to translate
     * @param  string|Zend_Locale  $locale     OPTIONAL locale/language to translate to
     */
    public function output($messageId, $locale = null)
    {
        call_user_func($this->_output_callback,
                       $this->translate($messageId, $locale));
    }

    ...
}

That is logical oliver... but we should first decide IF such a functionality should be added before going into details.

And for now I only received contras and no pros...


<?php $translate->print('My translated string', $locale); ?>

May generate invalid XML if translate output contains '<', '&' and so on.

This has already been pointed two comments before yours, Alexander... But these are details which can be solved later on.

The general question which I want to have solved is if we want to add such functionality or not.

Anyway I think the rendering should not be done within Zend_Translate as it is not its job...I'd rather use the display method of my rendering engine....

{quote} This has already been pointed two comments before yours, Alexander... But these are details which can be solved later on.

The general question which I want to have solved is if we want to add such functionality or not. {quote}

Issues like the one he pointed out are directly relevant as to whether functionality like this should be included or not. I really don't feel it's necessary or desirable to have {{Zend_Translate}} printing out strings.

Instead, the method signature of {{translate()}} should be changed to make it easier to use.

Instead of this:


print $translate->translate('my string', $locale);
sprintf( $translate->translate('my string', $locale), $param1, $param2, $param3);

It could be this:


print $translator->translate('my string', $locale);
print $translator->translate('my string', $locale, array($param1, $param2, $param3));

Users really should never have to touch {{sprintf()}} to use {{Zend_Translate}}.

The described functionallity was not accepted and as the idea proposed here got only negative feedback and not one positive I am closing this issue.

I would like to share my opinion in hopes of helping answer [~thomas]'s question:

I tend to agree that although such convenience code is attractive and useful, it appears to be more appropriate for userland. Including such an example in the documentation is a fine idea, provided that it encourages good PHP practices.

I feel that having the component write directly to STDOUT seems to unnecessarily couple the component to the view. Put another way, it would seem to be best practice to decouple the component from the responsibility of writing output and to allow the view logic to perform this, especially considering various output strategies, formats, and filtering requirements.

In summary, I would recommend against adding this to {{Zend_Translate}} proper.

{quote}Instead, the method signature of translate() should be changed to make it easier to use. Users really should never have to touch sprintf() to use Zend_Translate.{quote}

I already had made this change but it was not accepted by the devteam, so I had to revert it to the old behaviour.