ref#10671,#10152,#6009

This only makes sense if we support the plurals as well.

This seems abandoned, does this mean we'll have to add anIntlMessageFormatter ourselves in order to use\MessageFormatter?

Moving to 4.1. Rebase on master needed, where PHP 7.1 features can be used btw.

The issue with the PR in its current state is that it creates a community split: as soon as you configure Symfony to use the intl formatter in your project, it becomes incompatible with all bundles written using the default formatter (and this includes translations shipped in the core for validation errors). This makes it impossible to use it in a gradual way.

@stof indeed 😞 I guess the only way to resolve this is adding an extra argument to the trans method (CustomTransformerTranslatorInterface with an overwrite of trans() to add an additional argument) 🤔 not the nicest way but at least it would make is possible to use the new Transformer without breaking BC.

And we can't add a flag to a translation file because YAML and PHP for example use a hash at the root level, plus making@format_transformer a special key feels a bit strange 😛 and would still require a proper solution for XLIFF.

@sstok requiring codeusing the translations to provide the formatter to use to format this message looks really weird, because it puts this info in the wrong place. The template doing a translation calls has no idea which formatter implementation the original file was written for.

This only makes sense if we support the plurals as well.

The ICU message format supports pluralization based on any parameter (and on multiple ones), as this is one of the available features inside the string. We don't need a specifictransChoice feature in this case (which is an API limited to a single integer being the pluralization source)

I think grouping messages by formatter would solve the issue, something likedomain part.
I haven't yet to time to investigate on it, so if anyone interested on it would be welcomed 😄

Couldn't we make intl mandatory for Symfony 5? 😌

Closing in favor of#27399