when messing with entitys from within an console command or inserting entitys with doctrine fixtures (which are executed through the console) the locale is en_us.
If the default locale is not en_us, the translation-table gets filled with values for the en_us locale, even if it is not configured in the symfony app.
To avoid the problem, i have to set the translatable locale manually with:
The default locale should be set automatically for the console.
setTranslatableLocale is setting the current locale, not the default one. The default locale is always set. And the current one cannot be set automatically as there is no current locale in the CLI
When i'm executing a console-command, which is generating entities, like for example the Doctrine Fixtures (doctrine:fixtures:load), then i expect the "current" locale to be the default-locale.
What do you mean with "there is current locale in the CLI"?
I think there should be one. So if it's missing, should i open an symfony-issue?
Do you think the console command itself has to ensure, that the locale is set? Should a Command with entity-manipulation provide a --locale argument? But how can a vendor such as doctrine-fixtures know, that a doctrine extension requires the locale to be set?
But looking directly at the problem:
Why is translatable using the en_us-locale as the (default) current locale, when none is defined. Why not the default_locale, which is defined?
how do you determine the "current" locale in the CLI ? for the web part, the current locale is the locale stored in the Request object (or the Session one for 2.0) but there is no Request object in the CLI.
and the default locale can be configured through your config: https://github.com/stof/StofDoctrineExtensionsBundle/blob/master/DependencyInjection/Configuration.php#L24 en is the default when you don't configure it
sure, if you want to have a different current locale in the CLI as the default one, the command has to provide an argument (e.g --locale) in my opinion. But there should be something like the default locale.
The request and session objects are not available like you said, so i don't know how to solve this.
I have configured default_locale, but when executing a console command the locale is "en_US" and not the default_locale i configured for SoftDoctrineExtensionBundle. Thats my concern.
@stof Would it be a solution to add a call to setTranslatableLocale in the TranslatableListener service definition. This way, the default locale will be set a service creation. But since on each kernel.request event, the locale is overrided, it would not cause problem in the web part. This would then allow the CLI to use the default locale set by the user whitout breaking things in the web.
Put code above in Resources/config/listeners.xml in the definition of service stof_doctrine_extensions.listener.translatable (just before Line #35).
I tested rapidly in my application and it seems to works fine. Don't know if they would be draw backs to this idea. I'm suggesting this fix since it could be usefull. What do you think?
@l3pp4rd shouldn't the listener use the default locale by default instead of using en_US ?
both in translation listener are set to en_US as defaults. this is configuration specifics and its either user or bundle can configure it.
@maoueh proposal is a right choise for such case in the bundle.
@stof Is it ok with you? I can send a PR for this if you agree. Do you see something that could be wrong by doing so?
@maoueh yeah, please send a PR to the 1.0.x branch
thanks for this nice solution :)
Np, had the same problem, needed a solution, glad to help :)
@stof Can it also be applied to master ?
I just tagged 1.0.2 and merged 1.0.x into master. Thanks for the reminder. I thought about it when merging but I was working on something else and then I forgot.
Hehe no problem, thanks you for the merge.