Just found a situation where a callback is needed if the translations parameters are depending on the choice.
I need to handle a callback then.

@xabbuh Do you know how I can support something like

'choice_translation_parameters' => function ($choices, $key, $value) {    return ['%foo%' => $choices->getFoo()];}

Hi@xabbuh, I totally rework the PR and updated thesymfony/symfony-docs#13677

I change the way I implementedchoice_translation_parameters to work the same way it works forchoice_attr.
This allow to not pass the same translation_parameters to the choices.

WDYT about it ? :)

@xabbuh I don't know why thelow build failing. Can you help me ? :)

@VincentLanglet You should probably bump de dep ofsymfony/form to^5.2 in Twig Bridge.

@VincentLanglet You should probably bump de dep ofsymfony/form to^5.2 in Twig Bridge.

Indeed ! Thanks.

I think this PR is finally ready to review then. :)

@VincentLanglet you don't need to pass a translatable as key in thechoices array, you need to use thehttps://symfony.com/doc/current/reference/forms/types/choice.html#choice-label option to transform what you put in the choice array into a translatable object.

So yes, the feature does exists currently.

@VincentLanglet you don't need to pass a translatable as key in thechoices array, you need to use thehttps://symfony.com/doc/current/reference/forms/types/choice.html#choice-label option to transform what you put in the choice array into a translatable object.

So yes, the feature does exists currently.

Oh I didn't think it that way.

But, I propose the feature

'choice' => [    'form.order.yes' => true,    'form.order.no' => false,],'choice_translation_parameters' => [    'form.order.yes' => ['%company%' => 'ACME Inc.'],    'form.order.no' => [],],

And you recommend

'choice' => [    'form.order.yes' => true,    'form.order.no' => false,],'choice_label' => function($choices, $key, $value) {    $parameters = [        'form.order.yes' => ['%company%' => 'ACME Inc.'],    ];    return new Translatable($key, $parameters[$key] ?? []);}

I have trouble to see this solution as simpler.
So It could take some time before the introduction of a deprecation for the first solution, if we had one some day.

I'm not sure that the "Translatable should be the only option" is the best strategy for the developer.

@xabbuh Do you have some time to review this PR ? :)

Personally I tend to never use the keys inchoices for labels and always definechoice_label because I find it cleaner so I would do something like this :

'choices' => [    true,    false,],'choice_label' => function ($choices, $key, $value) {    if ($value) {        return t('form.order.yes', ['%company%' => 'ACME Inc.']);    } else {        return t('form.order.no'),    };}

Of course this example doesn't looks that good but in most cases your choices will contains the necessary data to construct the full translation.

And even if it is a bit more verbose I think it's a better solution since it keeps the translation key and the translation parameters close to each others.

Personally I tend to never use the keys inchoices for labels and always definechoice_label because I find it cleaner so I would do something like this :

'choices' => [    true,    false,],'choice_label' => function ($choices, $key, $value) {    if ($value) {        return t('form.order.yes', ['%company%' => 'ACME Inc.']);    } else {        return t('form.order.no'),    };}

Of course this example doesn't looks that good but in most cases your choices will contains the necessary data to construct the full translation.

And even if it is a bit more verbose I think it's a better solution since it keeps the translation key and the translation parameters close to each others.

It's easier when it's a true/false case.

But if choice are let's say[1, 2, 3, 4], you ends with

'choice_label' => function ($choices, $key, $value) {    if ($value === 1) {        return t('form.order.1', ['%company%' => 'ACME Inc.']);    } elseif ($value === 2) {        return t('form.order.2', ['%company%' => 'ACME Inc.']);    } elseif ($value === 3) {        return t('form.order.3', ['%company%' => 'ACME Inc.']);    } else {        return t('form.order.4'),    };}

It starts to be verbose.

And if it was the recommended way, Symfony wouldn't use thekey of thechoices as label.

I find your solution over-complicated, you don't like mine.
I don't see any issue to do the same thing different ways. It will satisfied more developer.

For instancechoice_label can accept

function ($choice) {   return $choice->getFoo();}

And

'foo`

And none of these solution are deprecated.

@VincentLanglet Can you have a look at the failing tests?

@VincentLanglet Can you have a look at the failing tests?

I fixed the error I got with missing space inresolved_form_type_1.txt,
But maybe there should be something about the

trim_trailing_whitespace = true

line in the.editorconfig file. My IDE is just automatically removing the trailing whitespaces every time.

I also remove the deprecation I added since there is already one.

The "Symfony\Component\Form\ChoiceList\Factory\DefaultChoiceListFactory::createView()" method will require a new "array|callable $labelTranslationParameters" argument in the next major version of its interface "Symfony\Component\Form\ChoiceList\Factory\ChoiceListFactoryInterface", not defining it is deprecated.

But I don't know how to avoid getting this in tests. I'm getting this because theDefaultChoiceListFactory::createView doesn't have the$labelTranslationParameters in his definition, because it would be a BC-break.

@fabpot@xabbuh

We've just moved away frommaster as the main branch to use5.x instead. Unfortunately, I cannot reopen the PR and change the target branch to5.x. Can you open a new PR referencing this one to not loose the discussion? Thank you for your understanding and for your help.

Sure#38469