What will be the replacement for $translator->transChoice('some_message2', 10, array('%count%' => 10)); ?

$translator->trans('some_message2', ['__number__' => 10, '%count%' => 10], null, null, TransChoiceMessageFormatter::NAME); ?

It looks a bit weird to me. I think that if trans and transChoice are merged together we should have a way to automatically choose between the 2 (maybe automatically takes a '%count%' key is their isn't any '__number__' one or something like that?)

@Nicofuma merging them together looks better!

How would you envision this in the templates? Adding class names/constants is pretty annoying in twig. It also means that I have to pass a lot of default values if I want to specify that. It feels like you have a lot more boilerplate to achieve the same. Having to write down __number__ doesn't feel ideal either but having to rely on another pre-defined key is kind of magic as well.

What I know from experiences:

• For transchoice, you always have to define a number
• specifying the domain and locale is kind of annoying for most cases for the solution you present (messages domain/default locale)
• A lot of times I translate without parameters but with a different domain

So I think we can agree that something is bothersome in the current implementation but i don't think the solution you present will solve it and will possibly even decrease the DX.

Using multiple formatter is something rare but this allow us to migrate safely to IntlMessageFormatter.
Right now if we combine trans with transChoice in one formatter it'll reduce some boilerplate,

__number__ is provider for only BC break not for end-users, we can use %count% like we did in twig transChoice

{{ 'Hello world'|transchoice(count) }} //Before
{{ 'Hello world'|trans({ '%count%': count }) }} // After

So how would that be determined? I can have a %count% in my arguments without it being a transchoice.

$translator->trans($v, ['%count%' => 10], null, null, TransChoiceMessageFormatter::NAME);
// vs
$translator->transChoice($v, 10);

Where would it be less boilerplate? Maybe I missed something?

@iltar

So how would that be determined? I can have a %count% in my arguments without it being a transchoice.

agreed we should find another pre-defined key :/

Where would it be less boilerplate? Maybe I missed something?

As I said before TransChoiceMessageFormatter will be meged into TransMessageFormatter so we don't need to pass the formatter argument by default but we need to rely on a pre-defined key

What about trans_count ?

Ah okay, so it's the part where the key defines what type is used. In php you could use a constant but that would be cumbersome in twig. You could expose the value like {{ 'foo' | trans({trans.count: 10}) }}.

Something else that popped my mind, simply no key: $translator->trans('foo', [10]). Sadly it's typehinted as array for this case. In twig it could be {{ 'foo' | trans(10) }} though.

At first glance this looks to me like a serious step back in DX:

{# before #}
{{ 'Hello world'|transchoice(count) }}

{# after #}
{{ 'Hello world'|trans({ '%count%': count }) }}

// before
$translator->transChoice('some_message2', 10, array('%count%' => 10));

// after
$translator->trans('some_message2', [TransMessageFormatter::TRANS_CHOICE => 10]);

My questions: What's wrong with the current transChoice() method? What's the problem we're trying to solve? Why the new code is longer to type and harder to learn? Thanks!

@javiereguiluz: take a look at how message formatter class works.
This is what aitboudad would like to support.

@mvrhov yes, but I'd prefer if we first focus on the before/after changes for end users and then we care about the internal implementation. For now I feel that this proposal is worse than the current situation.

@javiereguiluz having 2 fonctions that achieve the same behavior looks wrong to me
and I think tranchoice will be useless for custom formattter such as IntlMessageFormatter or ExpressionsMessageFormatter. The main goal for me is to make IntlMessageFormatter as default formatter.

we can keep tranchoice as a helper method but IMO it shouldn't be part of TranslatorInterface
if you have any suggestions I would be happy to implement it ;)

@aitboudad Actually the only times I've used the transchoice, I've done so via twig and never in the code. I find it a rare occasion having to use the translator directly in the code in the first place (but does happen).

@aitboudad here it is how Translator works today from the controller and the templates:

// simple
$this->get('translator')->trans('Hello');

// placeholders
$this->get('translator')->trans('Hello %name%', ['%name%' => 'Fabien']);

// pluralization
$this->get('translator')->transChoice(
    'There is one apple|There are %count% apples',
    10,
    array('%count%' => 10)
);

// selecting the catalogue
$this->get('translator')->trans('Hello', [], 'admin');

// selecting the locale
$this->get('translator')->trans('Hello', [], 'messages', 'fr_FR');

{# simple #}
{% trans %}Hello{% endtrans %}
{{ 'Hello'|trans }}

{# placeholders #}
{% trans with { '%name%': 'Fabien' } %}Hello %name%{% endtrans %}
{{ 'Hello'|trans({'%name%': 'Fabien'}) }}

{# pluralization #}
{% transchoice count %}
    {0} There are no apples|{1} There is one apple|]1,Inf[ There are %count% apples
{% endtranschoice %}

{{ '{0} There ...|{1} There ...'|transchoice(count) }}

{# selecting the catalogue #}
{% trans from 'admin' %}Hello{% endtrans %}
{{ 'Hello'|trans({}, 'app') }}

{# selecting the locale #}
{% trans into 'fr_FR' %}Hello{% endtrans %}
{{ 'Hello'|trans({}, 'messages', 'fr_FR') }}

Please, provide the equivalent examples for the new way of using the Translator that you are proposing, so we can compare. Thanks!

@javiereguiluz
For php:

 // pluralization
+ use Symfony\Component\Translation\Formatter\TransMessageFormatter;
+
-$this->get('translator')->transChoice(
+$this->get('translator')->trans(
     'There is one apple|There are %count% apples',
-    10,
-    array('%count%' => 10)
+    array(TransMessageFormatter::TRANS_CHOICE => 10)
 );

in Twig (I defined global variable transchoice = TransMessageFormatter::TRANS_CHOICE):

 {# pluralization #}
-{% transchoice count %}
+{% trans with { transchoice: count } %}
     {0} There are no apples|{1} There is one apple|]1,Inf[ There are %count% apples
-{% endtranschoice %}
+{% endtrans %}

-{{ '{0} There ...|{1} There ...'|transchoice(count) }}
+{{ '{0} There ...|{1} There ...'|trans({transchoice: count}) }}

@aitboudad thanks for the info. I've updated your comment to add the missing use import.

Does the new system mean that %count% is a hardcoded variable name in translation messages? If not, how could we implement this example with the new proposal?

$this->get('translator')->trans(
    'There is one apple|There are %num% apples', 5, ['%num%' => 'five']
);

@javiereguiluz

$this->get('translator')->trans(
    'There is one apple|There are %num% apples',
    array(TransMessageFormatter::TRANS_CHOICE => 5, '%num%' => 'five')
);

we can still using %count%:

$this->get('translator')->trans(
    'There is one apple|There are %count% apples',
    array(TransMessageFormatter::TRANS_CHOICE => 5, '%count%' => 'five')
);

@nicolas-grekas you can push now!

@aitboudad thanks, I just push forced one last time, addressing a few minor things meanwhile.

I think this PR is ready to merge, failures are false positives.
@aitboudad would you be able to work on a doc PR if worth it?

why not :), I'll try to work on it next weekend.

@nicolas-grekas I missed to mention the doc PR #8284, I guess the PR is ready to merge.

Thank you @aitboudad.