ping @symfony/deciders

I see a big issue with this implementation: the symfony formatting and the Intl formatting are totally different, and your implementation expects to choose one of them only. But the whole bundle ecosystem relies on the Symfony formatting (including validation translations in Symfony itself). This means that the only way to use the intl formatter is to stop using any third-party translations (you have to provide them again in the intl format), which does not give us any chance to deprecate the old system in favor of intl formatting (which is indeed much more powerful than the simple transchoice format of Symfony).

What I would like to see (if it is possible) is a way to use both formatters in parallels (some messages using the intl format, and other messages using the symfony format), to allow progressive migration.

@stof well what do you think to add a converter that convet the lagacy message into intl format when the IntlMessageFormatter was chosen ?

Well, if such conversion is possible, it would be a great news for the migration to the intl format. but the implementation needs to be careful to be able to load files providing both.
but there is another case which needs to be converted if needed: currently, the translation uses the key passed as argument as translated string in case the catalogue does not have it. this should take care of the conversion when needed too.
and the conversion is not only about pluralization, but also about placeholders.

However, if we want to switch to the IntlMessageFormatter (which seems a good idea to me), we would need to provide a stub implementation of the IntlMessageFormatter to avoid the hard dependency on intl just for that (and this stub implementation should probably be able to support rules for any locale, like our existing MessageSelector, not only for en, otherwise we would still rely on intl)

@stof I added LegacyIntlMessageFormatter to fallback the legacy messages (seems it work as expected) + deprecated transChoice.
can you review it please ?

@symfony/deciders is there anyone interested to provide a stub implementation of the IntlMessageFormatter ?

closing in favor of #18314, the IntlFormatter will be add once #18314 merged