Как перевести заполнитель в EntityType? - PullRequest
Новая
       24

Как перевести заполнитель в EntityType?

0 голосов
/ 31 октября 2019

Я создаю форму с элементом EntityType, проблема в том, что я не могу перевести заполнитель.

Вот мой код: 

$builder
        ->add('Products', EntityType::class, [
            'mapped' => false,
            'expanded' => true,
            'multiple' => false,
            'required' => false,
            'class' => Product::class,
            'choices' => $options['step']->getProducts(),
            'placeholder' => 'form.mat.alreadyOwned',
            'label' => 'form.mat.alreadyOwned',
            'translation_domain' => 'messages'
        ])

Когда я использую перевод form.mat.alreadyOwned в качестве метки, он работает нормально, но я бы хотел использовать его вместо заполнителя. Чего мне не хватает?

С нетерпением жду любых советов или уловок, которые вы можете предложить!

[ОБНОВЛЕНИЕ] Как указал @gp_sflover, я не пытаюсь заменить общий заполнитель,но один для пустого значения. Это появляется только если вы установите required на false.

1 Ответ

1 голос
/ 04 ноября 2019

После некоторых исследований и размышлений места, где на самом деле используется placeholder, весьма ограничены (как и должно быть). Однако конкретный перевод заполнителя не является особым случаем (к сожалению).

Для каждого варианта в ChoiceType добавляется ChoiceView. Также для заполнителя добавляется ChoiceView, который наследует параметры формы (что является довольно разумным выбором для ChoiceType), включая параметр translation_domain, который указывает, что выбордолжны быть переведены (все они). В некотором шаблоне ветки есть ссылка, которая специально управляет переводом в ветке ветки для нераскрытых типов выбора . Тем не менее, они не раскрывают конкретный практический ответ о том, как конкретно обрабатывать переводы для заполнителя в ChoiceType.

Для EntityType это не меняется.

Так что есть несколько подходов, некоторые из которых могут быть абсолютно бесполезными ...

перевести заполнитель прямо здесь при создании формы

Хотя это концептуально не самый красивый вариант,ИМХО, это все еще самый практичный. По сути, в Symfony 4 формы могут получать зависимости в своем конструкторе через автоматическое подключение, поэтому внедрение TranslatorInterface откроет возможность преобразования заполнителя с языковым стандартом запросов (которыйдля переводчика автоматически устанавливается прослушиватель событий): 

public function __construct(TranslatorInterface $translator) {
    $this->translator = $translator;
}

, и в вашей buildForm вы можете использовать его для перевода заполнителя 

$builder
        ->add('Products', EntityType::class, [
            'mapped' => false,
            'expanded' => true,
            'multiple' => false,
            'required' => false,
            'class' => Product::class,
            'choices' => $options['step']->getProducts(),
            'placeholder' => $this->translator->trans('form.mat.alreadyOwned'),   // <-- change
            'label' => 'form.mat.alreadyOwned',
            'translation_domain' => 'messages'
        ])

, чтобы не скрывать другие параметры, которыепо моему мнению, почти все излишни ...

установить choice_translation_domain для всех записей, включая заполнитель

, очевидно, это может ивероятно, это приведет к проблемам, если когда-либо будет сущность, чья метка выбора соответствует ключу в переводчике ... и она не предназначена для перевода. но он будет переводить заполнитель с той же translation_domain ...

адаптировать визуализацию формы и проверять заполнитель

это проблематично, так как вам нужно назначить тему формы /визуализация формы для всех соответствующих форм. у заполнителя действительно есть уникальное имя ('placeholder', кто бы мог подумать), поэтому его вполне можно использовать для достижения этой цели. Однако установка другого домена перевода может быть очень сложной задачей. (если вы попытаетесь это сделать, это немного неприятно)

напишите свой собственный тип сущности (опционально добавив собственную визуализацию формы)

теоретически вы можете создать свой собственный EntityType и обработатьзаполнитель правильно там. как ... добавление домена перевода к представлению выбора и форме, а что нет. Для вдохновения / справок обратитесь к ChoiceType, EntityType и DoctrineType (родительский тип).

...