-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Added support for help_translation_parameters and label_translation_parameters #6206
Conversation
Co-Authored-By: tkuska <[email protected]>
Co-Authored-By: tkuska <[email protected]>
…anslation_parameters
Build is failing, can you rebase? |
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.
I had trouble to understand this file... 🤔
Why label_translation_parameters
and help_translation_parameters
would be accessible like this, when we're doing sonata_admin.field_description.translationDomain
or sonata_admin.field_description.help
for others params ?
Shouldn't we use something like sonata_admin.field_description.option.foo
?
https://symfony.com/blog/new-in-symfony-4-3-improved-form-translation, you can define them in form types. |
I agree with a classic formType. But here, we're working with FieldDescription too. Here
You can see that we're not just using There is also
So if I want to get
|
Co-Authored-By: tkuska <[email protected]>
Co-Authored-By: tkuska <[email protected]>
…anslation_parameters
Added access to help_tranlslation_parameters and label_translation_parameters to fieldDescription
Ok, rebase done, and i've added label_translation_parameter and help_translation_parameters as options to fieldDescription, now hey are accessible like:
Is that OK? |
ooops i messed sth up during rebase. |
src/Admin/BaseFieldDescription.php
Outdated
public function getHelpTranslationParameters() | ||
{ | ||
return $this->getOption('help_translation_parameters'); | ||
} | ||
|
||
public function getLabelTranslationParameters() | ||
{ | ||
return $this->getOption('label_translation_parameters'); | ||
} |
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.
I'm not sure we want to have quick getter for every option.
Shouldn't we remove them and only use
options. label_translation_parameters
to access this kind of property ?
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.
ok, just misunderstood your comment, i thought you want it accessible via getter
So if I want to get
foo
, how can I know if I need to write
foo
sonata_admin.field_description.foo
sonata_admin.field_description.options.foo
?
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.
I never correctly understood the way this file works.
What I wanted to say is that I don't know why sometimes we're using foo
and sometimes we're using sonata_admin.field_description.options.foo
. Which one should we use to this work properly ? And how to know this ?
We're indeed also using sonata_admin.field_description.foo
sometimes but I feel like it's not a good idea to always add getter, because we need to add them to the interface (and it's a BC-break). Working with $options is easier.
In a PR I prepare for 5.0 (so in a long long time), I will try to remove some sonata_admin.field_description.foo
getter.
sonata-project/SonataDatagridBundle#239
src/Form/FormMapper.php
Outdated
if (isset($options['label_translation_parameters'])) { | ||
$fieldDescription->setOption('label_translation_parameters', $options['label_translation_parameters']); | ||
unset($options['help']); | ||
} |
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.
I don't think we need this, all options are set by default to the $fieldDescription
.
There is special behaviour for label
, template
etc because the data is saved in a $label
, $template
property instead of the $options
property (don't really know why btw...).
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.
BTW it currently introduce a bug since you're unsetting $options['help']
.
src/Form/FormMapper.php
Outdated
if (isset($options['help_translation_parameters'])) { | ||
$fieldDescription->setOption('help_translation_parameters', $options['help_translation_parameters']); | ||
unset($options['help']); | ||
} |
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.
Same.
IMHO we should only promote
How to know which one we should use and when ? Is it always the same value ? @sonata-project/contributors @tkuska Does someone understand something about this file ? 😅 |
Apparently, |
If I understand correctly:
This would mean that your PR was originally better without my request @tkuska, sorry. 😔 Edit: And yeah ! We should deprecate |
OK, i will roll back to use standard Should i do something with i heve found something like this in
It looks like 'help' option is prepared to be part of field description in 4.0? |
…tion_params for checkboxed and radios too (aswell as it works with standard Symfony forms)
Thanks !
If you want to, it could be great. But you should do it in another PR. We have to
I create an issue to not forget about this #6207
We added this because we were already calling |
By the way, see #5820 (comment) You could add it too. |
OK, i will create new PR for translation parameters in filter fields and another one with |
Thanks. I approved this PR. As soon as another @sonata-project/contributors approve it too, we'll merge it. |
I think this patch deserves some examples at |
Wouldn't it better to try to support every Symfony options and refer to the Symfony documentation instead ? |
@tkuska have you started working on deprecating the |
@franmomu no, i fighting with passing label_translation_parameters in filter fields right now so you can take this |
Thanks @tkuska ! |
Subject
In Symfony 4.3 form translation was improved, there was added parameters like 'label_translation_parameters' and 'help_translation_parameters' but these parameters was missing in SonataAdmin templates
Changelog