Bernhard and Fabien, I'm grepping around and it looks like most of the Intl classes do get used in the form framework.
It is possible to provide bare-bones plain PHP implementations of these classes directly inside a wrapper that first checks whether Locale already exists with class_exists(). Since most of the classes do get used I am inclined to think this is the simplest and most maintainable fix, in that you would continue to "just use it" and I would worry about keeping the plain-vanilla, one- locale fallback implementation working. Code of yours like this: ./Component/Locale/Resources/data/update-data.php: $lang = \Locale::getPrimaryLanguage($supportedLocale); And this: ./Component/Form/ValueTransformer/ NumberToLocalizedStringTransformer.php: const ROUND_FLOOR = \NumberFormatter::ROUND_FLOOR; Would just work. The check for this would need to be invoked in bootstrap code somewhere. Not sure where the best place for that call is. What do you think? On Jan 24, 11:23 am, Bernhard Schussek <[email protected]> wrote: > 2011/1/24 Fabien Potencier <[email protected]>: > > > I agree that we won't reimplement intl in PHP (again). But, we need a > > DateField that can work without intl (of course, you won't have months in > > your language, and it will default to a standard layout; but at least it > > should work). > > Good point, that should be doable. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
