[Form] Added locale option for intl form types. #23629
Conversation
|
//cc @ogizanagi |
|
Looks sensible to me. At first, I was just wondering how much this could relate to #23611. I.e, should we create this new |
|
I like the idea of Ideally it would check the SF translator first for any overrides :) and then bypasses translating in the view. |
|
It is possible to rework PR and add |
|
My concerns about using
Also, I think use-cases for this are very narrow actually; I don't think it's a blocker as the implementation should be straightforward and easily covered, but still, could you elaborate by describing your own use-case? That would probably help for the adoption of both this PR and #23611. cc @HeahDude |
The turnaround is we have
Not sure, only SF format is supported which is accepted by intl. So we can leverage it as a translator. Otherwise i'd call this option |
|
might be for another PR but should the Intl Form Types have use the (X)Html attribute "lang" for that? other thing: should the intl_locale be a calleable function? PS: i know that would make the choiceList more complicated |
|
@Hanmac : I think it's out of the scope indeed, but at least for the class SelfTranslatedLocaleType extends AbstractType
{
public function configureOptions(OptionsResolver $resolver)
{
$resolver->setDefault('choice_label', function ($value) {
return Intl::getLocaleBundle()->getLocaleName($value, $value);
});
}
public function getParent()
{
return LocaleType::class;
}
}For the |
|
@ogizanagi: that's why I said only language and Locale. Because the mapping from country to language isn't always clear. But if you can overwrite the choice_label then you might not even need your own type extension |
|
Can this be done for Assert Constraints or the form_errors() can force the language as well? |
| @@ -44,9 +46,12 @@ public function configureOptions(OptionsResolver $resolver) | |||
| return null; | |||
| } | |||
|
|
|||
| $this->locale = $options['locale']; | |||
There was a problem hiding this comment.
Even if the use case looks weird, this may be overridden for each use of the type in the same request.
There was a problem hiding this comment.
Does form types are shared services?
There was a problem hiding this comment.
Yes they are shared services re-used to build each of your form instances. So usage of class properties should be prohibited in most cases.
There was a problem hiding this comment.
We should probably deprecate the ChoiceLoaderInterface implementation in those types as done in #23648.
There was a problem hiding this comment.
agreed. It confused me before: it was so hard to find place where should I save locale from options 🤣
There was a problem hiding this comment.
It's either this, either decorating the CountryType's ChoiceLoaderInterface implementation when using the locale option, so we keep a cache of base choice list (and will always be used as before when not using the option). But this cache is not worth it to me.
There was a problem hiding this comment.
@Koc: Do you have some time to finish this?
There was a problem hiding this comment.
yes, will try do it during this last week before stabilization phase.
|
Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw. |
|
closing in favor of #26825 |
…hoice types (yceruto, fabpot)
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Form] Add choice_translation_locale option for Intl choice types
| Q | A
| ------------- | ---
| Branch? | master (4.2)
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #26737
| License | MIT
| Doc PR | symfony/symfony-docs#...
This PR adds possibility to show the list of elements for a custom locale different to the current one and proposes also deprecate the `ChoiceLoaderInterface` implementation from all of them, moving it to a separate class.
See related issue #26737 for full description and use-case.
After:
```php
$formBuilder->add('country', CountryType::class, [
'choice_translation_locale' => 'es',
]);
```
Alternative of symfony/symfony#23629
TODO:
- [x] Update `UPGRADE-*.md` and `src/**/CHANGELOG.md` files.
- [x] Add some tests.
Commits
-------
9592fa64cf moved feature to 4.1
e250dfa702 Add choice_translation_locale option for Intl choice types
…hoice types (yceruto, fabpot) This PR was merged into the 4.1-dev branch. Discussion ---------- [Form] Add choice_translation_locale option for Intl choice types | Q | A | ------------- | --- | Branch? | master (4.2) | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #26737 | License | MIT | Doc PR | symfony/symfony-docs#... This PR adds possibility to show the list of elements for a custom locale different to the current one and proposes also deprecate the `ChoiceLoaderInterface` implementation from all of them, moving it to a separate class. See related issue #26737 for full description and use-case. After: ```php $formBuilder->add('country', CountryType::class, [ 'choice_translation_locale' => 'es', ]); ``` Alternative of #23629 TODO: - [x] Update `UPGRADE-*.md` and `src/**/CHANGELOG.md` files. - [x] Add some tests. Commits ------- 9592fa6 moved feature to 4.1 e250dfa Add choice_translation_locale option for Intl choice types
If this sollution is acceptable, I will update other form types and validators.