-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[TwigBridge] Fixed a parameterized choice label translation #58395
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
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
Can we add a test that covers this change? |
@derrabus, added a test that covers the issue. Is this the correct place for such a test or should it be extracted? |
I think, this is fine. |
Found another issue with I'll make some more changes to fix problem. |
Added another test and a fix for the issue associated with it. |
ChoiceView::$labelTranslationParameters
property usage for choice label translation
the case of using a TranslatableMessage is expected though: the TranslatableMessage is embedding its own parameters. |
Yes, it turned out to be a PR covering behavior with different scopes of parameters (parent from In both cases, the parameters were previously lost. |
Thank you @7-zete-7. |
Currently, choice translation does not use the parameters assigned to them.
This pull request adds the use of parameters when translating choices.