Move %locale% to config.yml

[gerryvdm]

As per the official best practices, parameters.yml should be reserved for infrastrucure-related parameters. The default locale is a parameter which typically is application related, so I suggest moving it to config.yml.

[weaverryan]

This makes sense to me. Was there an original reason/use-case where the locale would be changed on a machine-by-machine basis?

[wouterj]

It was added in what I believe was the first commit of this repo: db5b6be So I don't think there is any original reason that we can find.

I'm not sure if I like it to have a parameters definition in config.yml. I think it might confuse people that we are configuring some sort of parameters bundle in there.

[gnugat]

Is the locale parameter used anywhere else? If not we can directly set translator.fallback and default_locale to "en"...

[Pierstoval]

Also, isn't this strange that the translator parameter has a fallback parameter ? Shouldn't be set automatically to the default_locale parameter ? Wouldn't this be better in removing the locale parameter in parameters.yml ?

[weaverryan]

@Pierstoval You may have a point, but we should talk about that elsewhere - in the core :).

@wouterj for me, I actually like having parameters in config.yml, because I can say "see, parameters.yml isn't special - any file can have parameters. This file just isn't committed to the repo". But since you also talk to a lot of people who are learning, you can tell me if you disagree.

@gnugat Yes, we could just remove the parameter altogether, but these probably are usually set to the same value (?). So if I want to use fr, I would now need to change it in both spots - I don't love that.

[Pierstoval]

Also, I'm thinking about BC. Many bundles use the default %locale% parameter as a pivot point to set up translations, for instance, and modifying so drastically this feature would break some BC on many projects.

As @weaverryan said, maybe it'd be better to discuss about this point in symfony core repository, especially on the master repo which will break many MANY BCs :D

[linaori]

@Pierstoval If %locale% doesn't exist, it could always be set in the parameter container, based on the chosen default language in the config

[Pierstoval]

In fact, that's what I wanted to suggest at first, but I don't know if it was explicit enough

[weaverryan]

Yea, I'd prefer not to have any magic setting of parameters, and I don't see the advantage. The change as proposed now is tiny, and reflect where (I think) parameters should live.

But I could propose 2 additional changes:

1. Add a comment to the top of parameters.yml.dist saying:

# Set parameters here that may be different on each machine where the app is deployed
# http://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration
...

2. Add a comment above the new parameters key in config.yml that says:

# Put parameters here that don't need to change on each machine where the app is deployed
# http://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration
parameters:
# ...

@gerryvdm Could you make that change?

I haven't heard any actual reasons agains this, so I'm 👍!

[Pierstoval]

@weaverryan Great ! 👍 👍

[wouterj]

Let me say something shocking: what about putting it in services.yml ?

I think adding parameters to config.yml will make people add services to it as well. That's not very great: config*.yml should only configure extensions, services.yml should load parameters/services, parameters.yml(.dist) should only contain infastructure-related parameters.

[gnugat]

I agree with @wouterj

[Pierstoval]

I don't know, when you say "config*.yml should only configure extensions". In fact, if it configured only extensions, maybe it'd need to be renamed as extensions.yml ?
"Config" is a word dedicated to configuration, and the locale is part of the configuration

[linaori]

@Pierstoval Interesting suggestion, but I don't think people know the concept of extensions in symfony, even though bundles are extensions on the container.

[Pierstoval]

You're right, that's why I think setting up the locale at the beginning of the config.yml file might be a better idea than putting it in services.yml where you set up... services, which are basically classes.

[wouterj]

@Pierstoval the only "Config" thing in Symfony is configuring DI extensions. The extensions can then do anything with the config they want (only load services depending on some settings, saving some settings as parameters in the container, etc). That's why it is very logical to use config.yml, there is no other config concept except from configuring extensions.

Then about "the locale is part of the configuration". It is indeed, it is part of the FrameworkBundle (as that's the bundle integrating i18n things): framework.default_locale. You can set this to "en" and you have configured the locale as part of the extension configuration.

However, since you need it multiple times and don't want duplication, Symfony has a feature that allows you to pass container parameters as values of the extension settings (using the %xxx% notation).

Now, the locale configuration part is still done in the config.yml file: framework.default_locale is still set in the config.yml file.

However, the value of it depends on a parameter and this parameter has to exist in the container. In order to do this, you need to load it in the container, thus: services.yml.

Loading this parameter on its own would not configure anything (as you don't have to use this parameters as value of framework.default_locale). The choice in the SE is to configure framework.default_locale in such a way that it is using a locale parameter that was loaded in the container. Configure: config.yml, loaded: services.yml

[weaverryan]

Hi guys!

I don't have much preference of config.yml or services.yml - they're all building the same container.

But practically speaking, locale is used out of the box in config.yml, so the user can see how it's used all in one place. And parameters are also likely to be used under DI extension config as well as services, so having parameters in the "main" config file (config.yml) feels natural to me. Slight +1 from me for config.yml. I actually agree with you points Wouter - but config.yml feels more practical.

Thanks!

[gerryvdm]

I added the comments, let me know if everything is ok now.

If I may chime in on the location, I do prefer config.yml over services.yml, as I think and feel the latter was added for adding your own proprietary service definitions, while %locale% is mainly used in the framework extension's configuration (which happens in config.yml).

[weaverryan]

👍 !

[stof]

I would also move the database_driver here. You don't change the database driver on each machine

[ReneeVandervelde]

That makes sense, I like the idea of moving that as well.
One minor concern to think about: Do you think that harms the getting-started experience for new users with a different environment set-up?

[gnugat]

@MaxvanderVelde good point, I think we have to make the distinction between 2 kinds of install:

• creation of a project
• installation of a created project

The first one is what the symfony installer should take care of, and it includes this kind of parameters.
The second one is what the Incenteev ParameterHandler takes care of, and it includes the parameters like database username and password.

[Tobion]

I agree database_driver should be moved as well to be correct.

[gerryvdm]

Not sure if database_driver really should be a parameter at all then.

[stof]

I generally configure it directly indeed

[Pierstoval]

Same, if it's considered as app-relative, having it directly in parameters might be useless.
By the way, maybe it can break BC, depending whether it's merged in master or 2.6/7 ? I don't know if this parameter is used elsewhere by service or conf, etc.

[weaverryan]

+1 for removing the database_driver parameter altogether and configuring it directly. It should make using sqlite a little bit easier I think anyways. I don't think this is a BC break, since the SE is just for new projects (and nothing internally currently uses the database_driver parameter anyways).

So, let's do it!

[fabpot]

+1 for moving the database_driver as well.

[weaverryan]

This still has a 👍 from me as-is! But I'm also 👍 for removing database_driver as a parameter altogether.

[Tobion]

As we discussed in symfony/symfony#14026 the secret MUST NOT be different for each machine. So this stays in contrast to the added comment at the top of the file.

[weaverryan]

Thanks Tobion - I see the comment here: symfony/symfony#14026 (comment)

I don't think this should hold up this PR, though - I think moving the secret somewhere else should be a different issue.

[stof]

@Tobion the secret must be the same for all server of a given deployment setup (i.e. all your prod servers). they need to share the secret. but it is the same for all other settings (if each prod server use a different DB, it could create weird stuff).
The secret should however be different for each deployment setup (your prod vs your preprod)

[Tobion]

correct, then I would suggest to rephrase the comment to "Set parameters here that may be different on each deployment target of the app, e.g. development, staging, production."

[weaverryan]

👍 for updating it to that exact wording

[gerryvdm]

Will look into the feedback on Monday!

[gerryvdm]

I changed the comment and removed the %database_driver% parameter.

[kristofvc]

+1

[aitboudad]

👍

Although each one has his prefered IDE/Text editor so what do you think about adding new params ide ?

# app/config/config.yml
framework:
    ide: "%ide%"

# app/config/parameters.yml.dist
parameters:
    ide: ~

[linaori]

@aitboudad what would be the point of defining an IDE in your parameters? That's unrelated to anything of symfony.

If my colleague is using Eclipse, a designer is using Sublime and I'm using PHPStorm, this would clash already (not working with .dist).

[aitboudad]

@iltar I didn't understand what you mean by this would clash already (not working with .dist). ?

[aitboudad]

@iltar it's related to symfony http://symfony.com/doc/current/reference/configuration/framework.html#ide

[linaori]

@aitboudad I was not aware of that option. But 3 different people with 3 different editors will not be able to use the default configuration and will put development configuration (ide link) in production.

[aitboudad]

@iltar I just learned in doc

This can be done by setting the xdebug.file_link_format in the php.ini configuration to the url string. If this configuration value is set, then the ide option will be ignored.

so this can be useless :)

[linaori]

This option is nice for people that don't have xdebug still, but a responsibility of the framework? I'd expect this kind of config under that debug bundle in the future

[Pierstoval]

It's clearly indicated in the docs that this parameter should be kept as system-relative.

I'd totally disagree with adding this ide parameter as it would confuse newcomers.
Plus, as said above, it is a problem for teams that have different IDEs. At , work I am using PhpStorm, my colleagues use Sublime, and the front-end devs use brackets and notepad++.
This option would be totally useless for us.

[weaverryan]

Let's discuss the ide thing elsewhere. As is, this PR is ready to go - it's got a 👍 from me :)

[stof]

👍

[xabbuh]

👍

[cordoval]

I am 👍 too, but honestly I am using a parameters_default.yml in some of my projects 👴

[fabpot]

Thank you @gerryvdm.