Placeholder translation in afe_select2_entity

[montabou]

In my params: fields: I have:

my_entity:
    formType: afe_select2_entity
    addFormOptions:
        configs:
            placeholder: my_entity.placeholder

The generated code in EditType is:

 'configs' =>   array(    'placeholder' => '$this->translator->trans("my_entity.placeholder")'

which seems correct

but the generated code in js is:

$field.select2({"placeholder": "my_entity.placeholder"})

I've tried to add translation into:

• Admingenerator
• Admin
• AvocodeFormExtensions
• messages

but no one works.

[ioleo]

The Select2 widget passes all the options "as is" without any logic only applying e4js filter to properly escape the values.

I think we could safely modify the e4js filter to apply translator on string values (that are not well formatted json arrays or js functions).

@sescandell Do you see any issues such modification could raise?

[ioleo]

I think it would go here

Replace:

<?php
if (is_string($var) && !preg_match($functionPattern, $var) && !preg_match($jsonPattern, $var) && !preg_match($arrayPattern, $var)) {
    return '"'.str_replace('"', '&quot;', $var).'"';
}

With:

<?php
if (is_string($var) && !preg_match($functionPattern, $var) && !preg_match($jsonPattern, $var) && !preg_match($arrayPattern, $var)) {
    return '"'.str_replace('"', '&quot;', $var).'"|trans';
}

Or something similar.. what do you think?

[sescandell]

@loostro

Well, it should work with your proposition (just have to handle translation_domain too).

[sescandell]

Hi,

@loostro : I was thinking about something: if you made this change (adding the |trans part in the export_for_js function) it might break codes where people use this filter outside of an admingenerator context.

So we need to find another way to fix that issue

[sescandell]

Hi @montabou

Actually, I'm a little bit surprised by the code you provided us... In my opinion, the generated code will not contains the translator call.

I just made a sample example of that case with the following configuration:

    tags:
            formType: afe_select2_entity
            addFormOptions:
                class: Acme\DemoBundle\Entity\Tag
                multiple: true
                configs:
                    placeholder: admin.thematic.placeholder.tags
                    width: 'off'

and this is the generated code I get from AdminGenerator

$formOptions = $this->getFormOption(
    'tags',
    array(
        'multiple' => true, 
         'em' => 'default',  
        'class' => 'Acme\DemoBundle\Entity\Tag', 
         'required' => false, 
         'configs' =>   array(   
             'placeholder' => 'admin.catalog.placeholder.tags',    
             'width' => 'off',  ),   
         'label' => 'admin.thematic.label.rules',    
         'translation_domain' => 'MyCatalogDomain',
));
        $builder->add('tags', 'afe_select2_entity', $formOptions);

So, actually, this is "normal" the output is not translated. I think the example you provided is wrong: your placeholder is not under configs but below addFormOptions (and... I'm still not very sure about that... I'm surprised the translator is called, maybe I just forget something in admingenerator process)

So, the thing is, we should not be able, from the generated template (so issue linked to AdminGenerator and not FormExtensions) to know that a given value from your config need to be "translated". This is up to you to handle that. Imagine you don't use this component in an AdminGenerator context. What you will necessary do to get the placeholder translated is:

class MyFormType extends AbstractType
{
    private $translator = null;

    public function __construct(TranslatorInterface $translator)
    {
        $this->translator = $translator;
    }
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->add('tags', 'afe_select2_entity', array(
                ...
                'configs' => array(
                        'placeholder' => $this->translator->trans('my_key', array(), 'my_domain')
                )
        ));

    }
    public function getName()
    {
        return 'my_form';
    }

}

So, IMO, there is no issue. You simply need to override the generated template and handle the translation by yourself. Precisly, here is what you should do:

Edit your controllers to inject the translator in your form

// File in src/YourDomain/YourGeneratedBundle/Controller/YourEntity/EditControler as an example, you need to make the same thing on the NewController ...
    protected function getEditType()
    {
        $type = parent::getEditType();
        $type->setTranslator($this->container->get('translator'));

        return $type;
    }

Edit your forms to update the config and add the method to inject the translator

class EditType extends BaseEditType
{
    private $translator = null;

    public function setTranslator(TranslatorInterface $translator) 
    {
        $this->translator = $translator;
    }
    protected function getFormOption($name, array $formOptions)
    {
        if ('tags' === $name) {
            $formOptions['configs']['placeholder'] = $this->translator->trans($formOptions['configs']['placeholder'], array(), array_key_exists('translation_domain', $formOptions)?$formOptions['translation_domain'] : null);
        }

        return $formOptions;
    }
}

And it should work.

Makes sense for you?

[montabou]

I've just checked again and the trans part is indeed missing in the EditType form. That's very strange, I think I've copied/pasted the code when I submit the issue...

I don't know think it's linked to that but since I've posted the issue I downgrade to bootstrap 2 as bootstrap 3 was too buggy on sf2ag.

I guess I can close the issue, I'm sorry if I was wrong. I will try to reproduce it.

[ioleo]

There is some major refactoring to the BS3 branch coming this week, along with new functionalities.

Also the FormExtensions will be updated to work well with BS3. I'll tweet about it when it's done. Stay tuned =)

[sescandell]

@montabou

Actually, regarding BS3, most of issues come from FormExtensions which is not, for now, "ready for BS3". Works are in progress to make FormExtensions BS3 compatible as @loostro already told you.

But I have some samples of production project using both AdminGen 1.1 and FormExtensions working pretty well (well... with some hacks here and there)

Thank you for your feedbacks and do not hesitate to contribute if you have some issues