Added support for help_translation_parameters and label_translation_parameters#6206
Added support for help_translation_parameters and label_translation_parameters#6206VincentLanglet merged 16 commits intosonata-project:3.xfrom tkuska:3.x
Conversation
Co-Authored-By: tkuska <tomasz.kuska@gmail.com>
Co-Authored-By: tkuska <tomasz.kuska@gmail.com>
…anslation_parameters
|
Build is failing, can you rebase? |
VincentLanglet
left a comment
There was a problem hiding this comment.
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 <tomasz.kuska@gmail.com>
Co-Authored-By: tkuska <tomasz.kuska@gmail.com>
…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.
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.
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
foosonata_admin.field_description.foosonata_admin.field_description.options.foo
?
There was a problem hiding this comment.
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.
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.
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']); | ||
| } |
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