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 the symfony/symfony-docs#13677

I change the way I implemented choice_translation_parameters to work the same way it works for choice_attr.
This allow to not pass the same translation_parameters to the choices.

WDYT about it ? :)

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

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

@VincentLanglet You should probably bump de dep of symfony/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 the choices array, you need to use the https://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 the choices array, you need to use the https://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 in choices for labels and always define choice_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 in choices for labels and always define choice_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 the key of the choices 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 instance choice_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 in resolved_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 the DefaultChoiceListFactory::createView doesn't have the $labelTranslationParameters in his definition, because it would be a BC-break.

@fabpot @xabbuh

We've just moved away from master as the main branch to use 5.x instead. Unfortunately, I cannot reopen the PR and change the target branch to 5.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