-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Translation] Added intl message formatter. #20007
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
), | ||
array( | ||
'4,560 monkeys on 123 trees make 37.073 monkeys per tree', | ||
'{0,number,integer} monkeys on {1,number,integer} trees make {2,number} monkeys per tree', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point in MessageFormatter
abstraction if at the end you are coupled with specific implementation?
This only makes sense if we support the plurals as well. |
This seems abandoned, does this mean we'll have to add an |
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 |
@sstok requiring code using 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.
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 specific |
I think grouping messages by formatter would solve the issue, something like |
Couldn't we make intl mandatory for Symfony 5? 😌 |
Closing in favor of #27399 |
…, Nyholm) This PR was merged into the 4.2-dev branch. Discussion ---------- [Translation] Added intl message formatter. | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | replaces #20007 | License | MIT | Doc PR | This PR will replace #20007 and continue the work from the original author. I've have tried to address all comments made in the original PR. Commits ------- 2a90931 cs fb30c77 Be more specific with what exception we catch b1aa004 Only use the default translator if intl extension is loaded f88153f Updates according to feedback 597a15d Use FallbackFormatter instead of support for multiple formatters 2aa7181 Fixes according to feedback a325a44 Allow config for different domain specific formatters b43fe21 Add support for multiple formatters c2b3dc0 [Translation] Added intl message formatter. 19e8e69 use error 940d440 Make it a warning
Related to #18314