Repository: https://github.com/symfony/intl
Documentation: https://symfony.com/doc/current/components/intl.html
Unicode: https://home.unicode.org/technical-quick-start-guide/

Responsabilities

Currently, it seems to me this component:

• provides a polifill-ish layer for the intl PHP extension
• provides exhaustive formatting + locale data for countries, currencies, date, ...
• provides methods to check ISO codes or identifiers
• provides a dictionnary emoji -> description for every possible combinaison

Opiniated remarks

Two comments highlight the "blurred lines" I believe this component navigates:

1) Access or data ?

This component provides access to the localization data of the ICU library.

Maybe my english is in fault, but it seems to me it does not provides access to the data... it provides the data.

2) Unicode = CLDR + ICU + UTC

This component provides access to the localization data of the ICU library.

CLDR (where the emoji data comes from) is not in the ICU library. I'm quibbling over details here, i know. But i think that illustrates the volatile "scope" and "responsabilities" of this component.

So we come close to the problem...

The data included in the Intl component is massive (especially the emoji descriptions), and will grow more every semester.

I looked at the following cases

• source code
  • symfony/symfony : https://github.com/symfony/symfony/archive/refs/heads/7.0.zip
  • symfony/intl : https://github.com/symfony/intl/archive/refs/heads/7.0.zip
• installed
  • standalone: new folder + composer require symfony/intl
  • webapp: new folder + symfony create --webapp

Versions:

• 6.0 6.1 6.2 6.3 6.4 7.0
• Emoji data were added in 6.2

Some metrics...

So symfony/intl accounts for 30% of the files in the monorepo ... and nearly 75% of its total disk size.

...over time

Size (in MB) of the sources

It was already big in previous versions, but since the emoji data integration, it's off charts.

The symfony/intl alone is twice as big as: all the other components, all the bridges and all the bundles. Combined.

And it's not over. At all.

Why it'll grow more

The ICU components used in the component are well-defined and constrained by 'real-world' factors, so we can expect minor changes regarding countries, formatting data, etc. It's unlikely, for instance, that 200 new countries will suddenly emerge in 2024.

However, emojis may present a major challenge in the near future. New ones are added with every CLDR release. Except for a significant drop (like the upcoming 2000 hieroglyphs), this should be a gradual increase.

What bothers me more is the 'combinatorial nature' of these descriptions. We generate a line of text for every combination. And that's why this component is so large. But it's just the beginning of what could be exponential growth.

As of today, the 'hand emoji' has variations for skin color (I'm not certain, but let's say there are 6 possible colors), and emojis with multiple people often vary by gender ('boy and two girls').

In the upcoming release, a new variable is the concept of 'left-handed' versus 'right-handed'. So, we'll create a new line for every existing emoji with a visible hand. But we'll need way more than just a new line, because of every emoji where two hands are visible. I don't remember if it's already implemented, but there was discussion about including the same thing for the age of a person, or some hairstyles.

So, the symfony/intl component could very soon be 50GB, and a short while later 10^80TB. But there's no way it reduces in size... or even slows its growth.

I see negative effect on three very different layers.

Developper Experience

Whether these values are low or not in absolute terms (and I have no doubt that everyone will have their own opinion on this)... the reality is that users are downloading a component that is twice as heavy as all the others combined... and this inevitably affects installation times, bandwidth, update times, static analysis, IDE indexing, etc. A prime example is Docker on macOS, which was a real pain until recently with Orbstack, and the performance nightmare was directly related to the number of files mounted in a volume.

Contributor experience

I've lost count of how many times I've seen a contributor propose a feature only to be told: it's userland. (Full disclosure, I understand and share this point of view). But it can be frustrating to see closed doors for a few classes, while at the same time Symfony contains hundreds of lines like 'young woman with dark hair and kid'

Real world consequences: Ecological & financial costs

I have no desire to open a debate (on either of those topics). But again, these small things have real-world consequences. We are talking about Symfony, so the impact is enormous, even on small matters

What is the real impact ?

Downloads data, as provided by packagist (collected today)

Let's agree on: "it's not without an impact".

For its quality

Please don't misinterpret my message. I'm not criticizing the value of the component or questioning its qualities. Besides, my opinion wouldn't have any value for that matter anyway. And i'm absolutely convinced a lot of people decide to install this component knowing what they do.

For another reason

But there are also people who install... Symfony. The recommended installation procedure, as outlined in the documentation on the website, is to install the web application skeleton, which requires symfony/intl.

To revisit the argument from earlier, I'm really not sure if anyone realizes after installation why its vendors directory is 80MB and what it's used for (young woman with...).

I'm unsure why symfony/intl is included by default in a new project, while other components are not. As a developer, I would appreciate the ability to install a small, lightweight application or to have more packages for the same amount of overhead :)

For another reason (bis)

"There is a third reason, and once again, I'm not fully understanding the situation (and may not have all the backstory required for it).

The Country validator requires symfony/intl to validate a given string as a valid ISO alpha country code. To do this, it tries to retrieve the list of country names (indexed by code) from the locale data. Consequently, it's not possible to use BIC, Country, Currency, and probably others without symfony/intl.

So, if a developer installs symfony/validator and then wants to validate a BIC, they cannot do so without downloading 80MB of locale-specific data.

Wouldn't it be simpler to have a couple of ISO classes/methods in the Validator component? Or perhaps create a small component just for that purpose? Because having to parse giant files just to check if "FR" is a valid ISO country code seems quite inefficient to me.