this implementation is wrong. the Twig_Environment should not be configured through the TwigEngine, as this means that thetwig service is not configured fully whne using it directly rather than using the templating component

I see your point, but do we have a better place where we can call methods of the Twig extensions?

@xabbuh Well, there is 2 solutions here:

• registering the Twig_Extension_Core explicitly (so that we have a private service for it)
• using a service configurator to apply the logic. An example can be foundin DoctrineBundle usedthere

@stof Thanks for pointing me towards service configurators.

ping @symfony/deciders

I addressed@Tobion's last comments and added an entry to the changelog.

@stof what do you think about#13554 (comment)

By the way, why is the DependencyInjection component not a mandatory requirement? Does this make sense at all?

ping @symfony/deciders Would be nice if we could get this into 2.7. Bumping the DependencyInjection version imho could be discussed afterwards.

👍

Thank you@xabbuh.

This is fine. As long as you dont have multiple locales. Wouldn't it make more sense to configure it (additionally?) via translation files?

I made that same argument here:#13552 (comment)

and got no love.

I agree there needed to be a better overall way to generally make changing formats easier, however, I see it the same way as@King2500 .

Date, number and even currency formats should be part of ( are defined by?) the end user's locale. If you only need one format, then you most likely only have your application working with users who live in one locale (if there are other reasons for changing the formatting in an application globally, please let me know, as I don't understand the reasoning/ use cases). If you have different users with different locales using the application, then you have to use different locale formats. How does this improvement work with those other locale formats?

Also, if you actually do need to use different formatting schemes than the locales offer (and again, I'd love to understand why this might be necessary in a global perspective), then the locale definition is what should be overridable (or possibly make custom locale definitions? Though, that makes even less sense...hmmmm.).

Or actually, this extension

http://twig.sensiolabs.org/doc/extensions/intl.html

has the right logic and I think should actually be part of the core twig package (of an internationally usable templating system). With it in the core, then the locales should be configurable as to which locales are used in the application (defined by each user) and/ or which are overridden or new or customized and how. So that way, when you create templates with variables needing formatting, Twig already takes the user's locale (or the special overridden formatting) into consideration and outputs the formatting accordingly (yes, I'd even leave out the filters and only use a filter, if overriding in the template is actually necessary).

If the addition of the extension to the core causes "too much overhead" and why others that don't really need it can avoid using it (and why it is an extension?), then I'd venture to say, the whole formatting system in Twig needs to be revisited. It wasn't created with an "international templating system" in mind, which any template system should be first and foremost.

Scott