[Intl] Add option to regenerate Intl data-set with Kosovo #59693
Conversation
|
I don't think the proposal that @javiereguiluz agreed on was to make projects regenerate the intl data in a different way in their deployment process (effectively changing the code of the component during their deployment process without any review of the actual effect of the script) |
|
What about putting the denylist in the generated src/Symfony/Component/Intl/Resources/data/regions/meta.php instead, and dump all countries (including Kosovo and its translations) in localized files? On runtime, we could then use the meta to filter by default, and provide a way to allow some extra countries on demand? |
I have many different branches around the ways I initially thought that I might have tunneled vision at this point. I will definitely try this too 👍 |
|
Friendly up @llupa |
|
Unlike the readme, you don't just execute a command, you also need a |
|
Something like this does the trick. What do you think? Obviously, we need to do the addition for all the relevant methods and the generator needs to be updated. Subject: [PATCH] NamesUserAssigned
---
Index: Countries.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/Countries.php b/Countries.php
--- a/Countries.php (revision 0bd68a922ebf783861fda60815575849c3afb0c4)
+++ b/Countries.php (date 1743607734798)
@@ -147,9 +147,13 @@
*
* @return array<string, string>
*/
- public static function getNames(?string $displayLocale = null): array
+ public static function getNames(?string $displayLocale = null, bool $includeUserAssigned = false): array
{
- return self::asort(self::readEntry(['Names'], $displayLocale), $displayLocale);
+ $names = self::readEntry(['Names'], $displayLocale);
+ if ($includeUserAssigned === true) {
+ $names = [...$names, ...self::readEntry(['NamesUserAssigned'], $displayLocale)];
+ }
+ return self::asort($names, $displayLocale);
}
/**
|
|
I went through the idea I posted and it doesn't work (see #54711 (comment)). |
I am starting this PR because the linked issue has had me debate with my code more than I'd like to. The core principle of the int-component, as far as I can understand, is too be a more slim data-dump of the ICU data-set and offer easy access to most requested information, like country codes, names, ISO alpha codes, for languages and countries, timezones, scripts and such.
I tried to make a dynamic data-dump as much as I could, but that would require heavy rewrite of the component's logic (see below). So, I decided for this PR as a starting point to let users regenerate all data themselves including Kosovo for projects that need it.
ToDo-s
There are other touch points that are ignored such as validation constraints because I am looking for comments from the community.
Alternative larger code change
I tried a proof-of-concept only changing the
PhpBundleWriterclass andRegionDataGeneratorclass to always return an array of 2 values when calling any of thegenerate*functions, one for the default data-set and one for the optional user-assigned (only XK in this case to keep data light). Then, I changed the template format to array merge recursively ifALLOW_OPTIONAL_USER_ASSIGNEDwastrue.This had the issue that it only works for php data format, and not for Json. So I have been playing around with making a new format of data that always has the default data (as is now) and an extra array / object with
XKand changed the relatedPhpBundleReaderandJsonBundleReaderto decide weatherXKneeds to be merged depending on the env var value. This looks promising but, again, I think it is such a big change, that I feel compelled to hear from core members opinion.PS. This component is definitely interesting.