-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC][Form] Change TimezoneType to Intl sources / translate timezone choice labels #28836
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
Comments
Whatever gets decided here, backward compatibility requires that the dependency to symfony/intl stays optional (as the form type is currently usable without it). |
of course :) BC guaranteed, however symfony/src/Symfony/Component/Form/composer.json Lines 18 to 21 in 261c0de
i actually expected it to be a soft-dep :) meaning either we should fix that (we recently updated the types to throw if unavailable :S) or option 2 is viable :D |
hmm indeed, I confused with the validator component, where it is a soft dependency. |
join the club :) i forgot to move the dep myself in #28610 now thinking about it.. is that a BC break or would a changelog note be sufficient? |
So i've compared the zones from To me what's important, is that all zones are compatible with Results are pretty close, the difference mostly comes from a few different notations ( E.g.
AFAIK we should follow ICU here.
Snippet used: https://gist.github.com/ro0NL/fd815d6242ff8ee8116ee1acfb6db9a7 |
This improvement would be great and would indeed bring consistency with the other Intl parts. Thanks for listing the differences. They are not very important ... but what are you proposing for existing apps that use the old TZ? How could they transition to the new TZ? Thanks! |
I've added option 5 in the issue, describing the ideal scenario: switch to Intl, while keep supporting any submitted value from the old PHP list. At this point i'd like to trigger a deprecation, but it might be a bit complex... not sure yet. More pragmatically would be to just make the switch as a new feature (option 2). Technically we did the same-ish in #28833 😅 If we accept the feature (one way or another), i can have a look after #28831 / #28846 |
I think the important thing for BC is that |
This PR was merged into the 4.2-dev branch. Discussion ---------- [Form] Deprecate TimezoneType regions option | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #28848 | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> I know i've added this option myself in 4.1, but given my recent development for #28624 i realized it's an opinionated feaure, which can/should be solved on user-side (`choice_filter/choice_loader` and/or `group_by`). - blocks translations as we dont have them (see #28831) - blocks possibility of switching to Intl zones which doesnt really have this filter feature (see #28836) ~While at it, i solved a few issues with `OptionsResolver` that is able to deprecate options as of 4.2 also.~ Fixed in #28878 - when resolved trigger the deprecation - allow to opt-out from triggering the deprecation - dont trigger deprecation for default values (only given ones) Commits ------- 5cb532d [Form] Deprecate TimezoneType regions option
This PR was squashed before being merged into the 4.3-dev branch (closes #31195). Discussion ---------- [Form] Add intltimezone input to TimezoneType | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #22302 (ref #28836) | License | MIT | Doc PR | symfony/symfony-docs#11463 cc @rvanlaak Commits ------- e169dfb [Form] Add intltimezone input to TimezoneType
…country mapping (ro0NL) This PR was squashed before being merged into the 4.3-dev branch (closes #31262). Discussion ---------- [Intl] Update timezones to ICU 64.2 + compile zone to country mapping | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #... <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> This PR compiles the zone to country mapping (and vice versa) from ICU data: https://github.com/unicode-org/icu/blob/master/icu4c/source/data/misc/windowsZones.txt I've recompiled timezones on master due #31162, i should do it once more when it's merged upstream. Having this data allows compatibility between PHP timezones and ICU; - https://www.php.net/manual/en/intltimezone.getregion.php - https://www.php.net/manual/en/class.datetimezone.php#datetimezone.constants.per-country For the timezone validator in Symfony, this would be required to have a compatible "regions" option, once it supports ICU as well (#28836 (comment)) Commits ------- 3018a7a [Intl] Update timezones to ICU 64.2 + compile zone to country mapping
This PR was merged into the 4.3-dev branch. Discussion ---------- [Validator] Allow intl timezones | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | ref #28836 | License | MIT | Doc PR | symfony/symfony-docs#11502 This PR considers the ICU timezones (#28831) as valid, as well as the PHP ones. Both can be used in `DateTimeZone`, but expired timezones cannot be used with `IntlTimeZone`. The `intlCompatibility` option ensures compatibility between both. Practically this allows for both `UTC` and `Etc/UTC`, where the latter should be preferred. I.e. currently `Etc/UTC` is considered an invalid timezone ... which it's not. Commits ------- 7294b59 [Validator] Allow intl timezones
…mezoneType (ro0NL) This PR was merged into the 4.3 branch. Discussion ---------- [Form] Add intl/choice_translation_locale option to TimezoneType | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #28836 | License | MIT | Doc PR | symfony/symfony-docs#11503 final step :) for now i think any form of grouping is a user concern (i.e. by GMT offset or area name); see #31293 + #31295 having a special built in `group_by' => 'gmt_offset'` util would be nice, and can be done in the future. includes #31434 Commits ------- 001b930 [Form] Add intl/choice_translation_locale option to TimezoneType
Description
Currently the TimezoneType does not depend on symfony/intl (unlike LanguageType etc.), but uses vanilla PHP based on
\DateTimeZone::listIdentifiers()
.There are several issues (#26851, #17628, #17636) that request to use localized zone labels.
For that i've finished #28831 to provide the actual translations, based on ICU, just like languages, etc.
However it doesnt mean we should switch from
\DateTimeZone::listIdentifiers()
toTimezoneBundle::getZoneNames()
per se, hence the RFC.I see several options:
\DateTimeZone::listIdentifiers()
and only translate usingTimezoneBundle
TimezoneBundle
as a new feature (including translating)intl => false
to optionally switchPersonally i'd prefer symfony/intl so there's no environment dependency, and we have better control to blacklist/mutate etc.
Related
input=intltimezone
to leverage\IntlTimeZone
as underlying modelregions
option relies on\DateTimeZone::listIdentifiers()
, so if in any scenario Intl will be used the option is incompatible, meaning we either implement a fallback or deprecate it all together (favored bygroup_by
to let the user decide in all cases)Thougts?
The text was updated successfully, but these errors were encountered: