Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove usage of legacy locale parameter #374
base: 1.10
Are you sure you want to change the base?
Remove usage of legacy locale parameter #374
Changes from 6 commits
eb294d2
9d5e422
c5ab2ed
9a9cbbe
9acdc42
b9dec16
db1f026
1c26d09
9737c93
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand all of these parameters were missing, but it would be more ordered if we add only
enabled_locales
anddefault_locale
here and the rest of them in a separate PR 😄 #beingPettyIsMyPassionThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I see, previously it was only a %locale% parameter. Dit it fallback previously to
'en'
too? If it didn't, maybe we should throw some exception to not assume anything that was not assumed before? 🤔 I just would like to keep it as close to the previous implementation as possible 🖖There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a BC layer, so throwing an exception here defies the purpose of this code.
It could trigger a deprecation error though, warning that this default will be removed and that it should be configured explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
en
is coming from the default value oflocale
parameter configured in Sylius, Sylius Standard and Sylius Plugin Skeleton, which all should be removed after this PR is merged.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have mixed feelings about it as well. What is more, it is bumped by the fact that we do not have tests for more than one config present here and a description of winning strategy (for now it is: 1. new resource config, 2. previous parameter, 3. Symfony parameter, 4. "en").
Another concern is that we are replacing the old parameter with the new one entirely, but both configurations may (and probably should) work together. This parameter is used in several places. This is the screenshot from the current version of Sylius-Standard:
So now - the best config would be to have
$config['translation']['default_locale']
defined together with the%locale%
parameter defined anyway - the application will work, and no deprecation warning will be triggered (as we have early return). Also, the application will work with the%locale%
parameter defined without our new config, but the deprecation will be triggered. If nothing is defined or only our new config - the whole application will collapse. Am I missing something?What I would recommend is as follows - the
%locale%
parameter should be declared together with the%sylius.resource.translation.default_locale%
if not present based on the new config (that could have "en" defined as default in config tree). If the%locale%
parameter is defined together with our new config, then the error/deprecation warning should be triggered(I'm not sure about which one). The last question remains - should the "%locale%" be overridden by our config, or should it override our default locale? I would say the latter, but I'm open to discussing it.Anyway, I'm also lacking the cases I've described exposed as configuration tests + test drive with the current Sylius and/or Sylius-Standard to check the correctness of the new solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have revisited this and I agree that it needs some changes.
The goal is to get rid of the
locale
parameter and use the new configuration.This means that internally, all Sylius packages, should remove the
locale
parameter and use the new configuration.The only way a
locale
parameter will still exist, is if it's still defined in the end user projects.That's where the BC layer comes in action and uses the value of the
locale
parameter to feed the new configuration, but only if it wasn't already explicitly set by the user.In this case, a deprecation error should be triggered encouraging the user to migrate from using the
locale
parameter to the new configuration.Here are the possible scenarios and the outcomes I think they should have:
locale
definedlocale
undefinedkernel.default_locale
andkernel.enabled_locales
. This will be the default behavior in new installs.There's a 5th scenario, which is a combination of the 4th scenario with Symfony 4.4, which does not have the
kernel.enabled_locales
parameter.There is another important detail to consider in this case: when
kernel.enabled_locales
is empty, all locales should be enabled.In the Resource Bundle context this is not a viable solution, so we should stick to the current behavior and only use the default locale as the only available locale by default.
This means that, when
kernel.enabled_locales
is empty (normal behavior) or is not defined (BC layer), the default value ofsylius.resource.translation.enabled_locales
should be and array with onlysylius.resource.translation.default_locale
.To achieve the above, the following modifications must be made to the currently proposed changes:
kernel.enabled_locales
is empty;sylius.resource.translation.enabled_locales
should fallback tosylius.resource.translation.default_locale
(instead of the current['en']
if no other options were found;$container->setParameter('sylius.resource.translation.default_locale', 'en');
should be removed and an error should be thrown if the default locale was not set any other wayWDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vvasiloi Thank you, this is an awesome explanation. I think your suggested change is perfect.