[Intl] Fix locale validator when canonicalize is true#60888
[Intl] Fix locale validator when canonicalize is true#60888nicolas-grekas merged 1 commit intosymfony:6.4from
Conversation
|
Actually, could you add a test covering this to prevent regressions (i.e. a test validation a string for which the canonicalization returns null with modern ICU) ? |
This should be handled by the LocaleValidatorTest of Validator component. |
no need to try to force a system library (which won't be possible from PHP anyway). And no need to skip the test if ICU is older (the test will still pass if canonicalization returns an empty string). |
I don't understand what I have to do then. |
|
Is the existing test failing when using ICU 76 (without your patch) ? |
|
@stof In fact, the problem is a little different than expected.
And, the actual validator test don't cover those 2 cases. I will make another PR, with clearer definition and tests. |
|
@rdavaillaud no need to make another PR. You could add a test in this PR using a long locale name. |
153eb6c to
11423aa
Compare
When canonicalize is set to true, and the value length exceeds INTL_MAX_LOCALE_LEN the validator throws an exception. The Intl Locale::canonicalize() method returns null when the value is too long and Locales::exists() only accept non null string. This commit allows to handle the null value as it should. [Intl] windows / php 8.1 INTL_MAX_LOCALE_LEN
|
Thank you @rdavaillaud. |
When canonicalize is set to true, and the value passed to the validator is not a valid locale, ext-intl Locale::canonicalize should return null.
This is not the case with ICU <76, and this method returns an empty string.
But with the latest ICU lib, this method really returns null.
The problem is with
Locales::exists()which only accept non null string.This commit handles the returned null value in the validator.