[fw-mvc] Re: Correct way to create a _()-ViewHelper for translations

Hmmm... could you provide some further details on these "technical
restrictions"? My example below works out of the box with current
ZF releases and requires no change to any piece of code, so I'm
pretty curious what these show-stoppers might look like.

Changing my very own gettext-tools would not be a problem as I'm
using a cute little self-written tool-chain for this job, with
xgettext's keyword-parameter (currently set to "_") already
configurable. However, code like

<?= $this->_('Hello') ?>

looks not really good, but at least better than

<?= $this->translate_('Hello') ?>

in your View-scripts - therefore I would prefer to keep my View-
Helper, if nothing speaks against doing so.

Best regards,
Thomas Gelf

Емил Иванов / Emil Ivanov schrieb:
> There were plans for providing a _ helper, but it turned out it is not
> possible due to technical restrictions.
>
> However, you can approach the problem from the other side - tune your
> gettext collection tool to harvest translate() functions.
> This is possible and easy with POEdit for example.
>
> Regards,
> Emil Ivanov
>
> 2008/9/17 Thomas Gelf <thomas@gelf.net
> <mailto:thomas@gelf.net>>
>
> As most scripts creating .pot files by parsing PHP source code expect
> a _() function, I really would like to keep them ;-) So as the easiest
> solution I figured out the following one:
>
> > // Filename: My/View/Helper/.php
> >
> > class My_View_Helper__ extends Zend_View_Helper_Translate
> > {
> > public function _($messageid = null)
> > {
> > return $this->translate($messageid);
> > }
> > }
>
> As of the unusual file- and class-name it looks like an awful hack,
> so my question is: is this the right way to do what I'm wanting to
> achieve? And if so: would it make sense for ZF to provide a
> _()-ViewHelper per default?
>
> Kind regards,
> Thomas Gelf