[intl] Support all locales by using CLDR data directly #11737
Comments
|
@bojanz thanks for opening this issue and thanks for helping us to solve "the infamous intl issue". At this moment, @fabpot is also trying to simplify the intl requirements for Symfony (see associated issue at #11447). Regarding your specific proposal, if I understand you correctly, you are proposing to embed all the CLDR data inside Symfony or even using the
|
|
I am proposing the general approach.
For example, an application certainly wants to keep currencies and languages in the database, but might not need the same for number_formats (since they don't think the users would want to modify them), so number_formats would just be cached. The format of the files themselves can easily be switched to something else (JSON?), though the cost of hitting the hard drive remains. |
|
IMO, the best format for files would be a php. Thus the ones running APC or newer versions with zend optimizer would benefit directly. For the ones not there would not be any change. |
|
Hi @bojanz, thank you for your input! :) In fact, Symfony already does include the CLDR data. However, this data is not stored in the main repository, but in the Icu component. The intl project you mention looks nice! It seems to me that it is practically doing the same as the Intl component, but excluding the stubs usable in case of a missing intl extension. The accessors for the CLDR data are being added in #9206. That PR isn't finished yet, but once @fabpot is done with fixing our current issues (should be soon), I am going to complete it. The API of that PR is slightly different than the one of the commerceguys intl project. It does not represent individual I18N objects (currencies, locales etc.) as objects - for performance reasons. For example, if you need a list of locale names, initializing an array of hundreds of Locale objects first adds noticeable overhead. So an identifier-based API is used instead, where the data for individual identifiers is accessible via a central service: if (Currency::exists('EUR')) { ... }
$euro = Currency::getName('EUR');
$names = Currency::getNames();If you want to help completing the PR and contribute to Symfony directly, that'd be great! :) If that sounds like fun to you, we can have a chat and talk about the details. Cheers! |
|
symfony/icu includes the CLDR data only in the v1.2 branch which requires the intl extension and icu. People without the intl extension are forced to use v1.0, which only has the "en" data. So we have no solution that works for everyone (people with and without the intl extension), with all locales. That's the reason why I wrote commerceguys/intl. I'd be glad to help symfony directly, if we can figure out how to resolve the main issue. |
@bojanz You are right. This was going to change with the mentioned PR, otherwise the CLDR data accessors clearly make no sense. Implementing NumberFormatter et al. for all locales (in other words: a complete PHP implementation of the intl extension) is an entirely different topic. Of course this would be nice to have, but somebody needs to do the work. So far, nobody volunteered. :)
Awesome! Let's chat tomorrow? You can find me on Google Hangouts, for example. |
|
I've talked to webmozart, and it turns out that symfony is indeed moving in the same direction, by deprecating symfony/icu and introducing symfony/intl-data which includes the CLDR/ICU data. I've opened issues against that work: #11885, #11886, #11887, #11888. |
If intl used the CLDR data directly, it could support all locales.
See https://github.com/commerceguys/intl for the how and why.
It's not attempting to mimic the intl extension API like symfony/intl does,
but it could easily be made to do so.
The text was updated successfully, but these errors were encountered: