I18n for forms

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

I18n for forms

Ralf Eggert
Hi,

I want to i18n my forms. I have a couple of modules which all use there
own text domain for the translator object. On the top of each view
script I use this one liner to set the text-domain for this script:

-----------------------------------------------------------------
$this->plugin('translate')->setTranslatorTextDomain('user');
-----------------------------------------------------------------

But unfortunately this does not work for the form view helpers. I need
to set the text domain explicity for all view helpers in every view
script that I want to use.

-----------------------------------------------------------------
$this->plugin('formText')->setTranslatorTextDomain('user');
$this->plugin('formLabel')->setTranslatorTextDomain('user');
$this->plugin('formSelect')->setTranslatorTextDomain('user');
$this->plugin('formSubmit')->setTranslatorTextDomain('user');
-----------------------------------------------------------------

This is awkward. I could write an event listener or something that is
triggered for each module to set the text-domain. But that is still just
messing around with some problem within the i18n view helper support.

Could the setting of the translator object and the text domain for the
view helpers not be centralized? Maybe every view helper thats needs
translator support could grab the current text-domain from the Translate
view helper?

Any ideas?

Regards,

Ralf

Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

Jurian Sluiman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

Ralf Eggert
Hi Jurian,

Ok, so you suggest to do the translation within form definition?

Did not thought about that but sounds reasonable at least for labels and
submit buttons. Though, passing multi options to a form select will need
extra work then since in some cases, these multi options are manipulated
within my service layer...

> If you can disable the translator in the view helpers, I would seriously go
> for above method.

How can I do this?

Regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

Jurian Sluiman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

Ralf Eggert
Hi Jurian,

> Can you explain?

Well, I have some forms which select options depend on the user logged
in. In the form creation I just add an empty array for the options and
when the current user is identified I pass the corresponsing multi
options to this form. If I want to solve this in my form factory I would
need to pass my Auth service and a data mapper for reading these options
which seems a little bloated.

Regards,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

cgmartin
In reply to this post by Ralf Eggert
Ralf/Jurian,

For the view helpers, the Zend\View\HelperPluginManager will attempt to add the translator to the helpers, but not the text domain.

In case it helps, here are two examples for changing the text domain for all view helpers, or for just the view helpers in a specific module:

Module.php:

use Zend\I18n\Translator\TranslatorAwareInterface;

class Module
{
    public function onBootstrap($e)
    {
        // Change View Helper Text Domain for THIS module
        $e->getApplication()->getEventManager()->getSharedManager()->attach('Zend\Mvc\Controller\AbstractActionController', 'dispatch', function($e) {
            $helperPluginManager = $e->getApplication()->getServiceManager()->get('ViewHelperManager');
            $helperPluginManager->addInitializer(function($helper) {
                if ($helper instanceof TranslatorAwareInterface) {
                    $helper->setTranslatorTextDomain('bar');
                }
            }, false); // At bottom of stack
        });

    }

    public function getViewHelperConfig()
    {
        return array(
            // Change the View Helper Text Domain for ALL modules
            'initializers' => array(
                'injectTranslatorTextDomain' => function($helper) {
                    if ($helper instanceof TranslatorAwareInterface) {
                        $helper->setTranslatorTextDomain('foo');
                    }
                },
            ),
        );
    }
}

I agree that with Forms it is a little awkward right now with the Text Domains...
Another thing to keep in mind in addition to the view helpers are the Validators and their error message translations. 

You could do something similar using events or initializers in your module with the Zend\Validator\ValidatorPluginManager (which also injects the translator). But note that the current Zend\Form\Element\* classes aren't using this ValidatorPluginManager for their default InputSpecification validators at the moment - You would need to build your own input filters and not rely on the element defaults.

Not sure if this solves your specific use case, but I would definitely be interested if anyone has ideas for improvement.

Cheers,
~Chris Martin


On Mon, Sep 24, 2012 at 6:09 AM, Ralf Eggert <[hidden email]> wrote:
Hi,

I want to i18n my forms. I have a couple of modules which all use there
own text domain for the translator object. On the top of each view
script I use this one liner to set the text-domain for this script:

-----------------------------------------------------------------
$this->plugin('translate')->setTranslatorTextDomain('user');
-----------------------------------------------------------------

But unfortunately this does not work for the form view helpers. I need
to set the text domain explicity for all view helpers in every view
script that I want to use.

-----------------------------------------------------------------
$this->plugin('formText')->setTranslatorTextDomain('user');
$this->plugin('formLabel')->setTranslatorTextDomain('user');
$this->plugin('formSelect')->setTranslatorTextDomain('user');
$this->plugin('formSubmit')->setTranslatorTextDomain('user');
-----------------------------------------------------------------

This is awkward. I could write an event listener or something that is
triggered for each module to set the text-domain. But that is still just
messing around with some problem within the i18n view helper support.

Could the setting of the translator object and the text domain for the
view helpers not be centralized? Maybe every view helper thats needs
translator support could grab the current text-domain from the Translate
view helper?

Any ideas?

Regards,

Ralf


Reply | Threaded
Open this post in threaded view
|

Re: I18n for forms

Ralf Eggert
Hi Chris,

> Not sure if this solves your specific use case, but I would definitely be
> interested if anyone has ideas for improvement.

Thanks for your input. Since I am quite satisfied with the solution of
translating text fragments within the form creation, I won't need it in
my current project. But it might be helpful in the future.

Regards,

Ralf