[MAGNOLIA-8065] DefaultI18nContentSupport wrongly forwards to fallback locale as opposed to default locale on sub pages Created: 15/Apr/21 Updated: 02/Feb/23 Resolved: 17/Dec/21 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | i18n |
| Affects Version/s: | 6.2.7 |
| Fix Version/s: | 6.2.15 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Jeffrey van der Heide | Assignee: | Nguyen Phung Chi |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | maintenance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 3.25d | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Template: | |||||||||||||||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||
| Task DoD: |
[X]*
Doc/release notes changes? Comment present?
[X]*
Downstream builds green?
[X]*
Solution information and context easily available?
[X]*
Tests
[X]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||
| Bug DoR: |
[X]*
Steps to reproduce, expected, and actual results filled
[X]*
Affected version filled
|
||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Sprint: | Global Maintenance 3 | ||||||||||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||||||||||
| Description |
|
When using a site definition like this:
I expect the default locale to be "en" (for international purposes, where as en_GB will be UK specific). This works fine for the homepage when the locale is set to "en", for subpages however the DefaultI18nContentSupport doesn't default to the default locale but instead resolves to the fallback on subpages. Resulting in a locale of "en_GB" where no locale was provided in the url as opposed to "en". For home page (correct): On subpages, actual: On subpages, expected: So that on the default/global website in absence of any content the fallback is used, but we don't set the locale for the website since that should still be the default. I've resolved for our project, but I think this might actually be unintended behavior across the board. Fix:
|
| Comments |
| Comment by Mercedes Iruela [ 20/Apr/21 ] | |
|
As states in the documentation you should use fallbackLocale to define defaultLocale in your sites. Do you find issues when using fallbackLocale instead of defaultLocale? | |
| Comment by Jeffrey van der Heide [ 20/Apr/21 ] | |
|
Fallback is not the same as default defaultLocale states which locale is the default, the locale that's supposed to be served on the "/'. The fallbackLocale is what gets used when a locale has no content available for a given language. As the documentation states;
Or as the code states:
Your documentation doesn't show defaultLocale (which just is a matter of missing documentation) The issue is; The workings of the falling back to the fallbackLocale work fine, it's just that the entire locale gets set to the wrong locale. This happens because it tries to return for the first part of the url which doesn't map to a locale but that method does return the fallbackLocale in absence of the locale in the url (which should pick up the defaultLocale, which in the example above is EN). By preventing the method returning the fallbackLocale too soon this now works correctly with my amendment as shown above. If I visit the website on the "/" the locale should be defaultLocale, not fallbackLocale that's unexpected behaviour. | |
| Comment by Mercedes Iruela [ 22/Apr/21 ] | |
|
Hello Jeffrey, We discussed the issue internally:
Thanks for reaching out and for helping us to improve the product. Best regards, Mercedes | |
| Comment by Jeffrey van der Heide [ 30/Apr/21 ] | |
|
Hope to find some time for a PR soon. | |
| Comment by fabian schneider [ 19/Jan/22 ] | |
|
The fix for this issue limits the possible locales to whatever is in `Locale.getAvailableLocales()`. This prevents us from updating to 6.2.15. We have content in Tswana (tn) and Northern Soto (nso), which is no longer supported. Is this on purpose? Are there any ways to add locales to this list through configuration? | |
| Comment by Richard Gange [ 19/Jan/22 ] | |
|
fschneider | |
| Comment by fabian schneider [ 19/Jan/22 ] | |
|
@rgange I will try to do that. I think a clean solution would be to check the availability in the locales of the current site. | |
| Comment by Richard Gange [ 19/Jan/22 ] | |
|
Noted |