[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: PNG File image-2021-04-15-17-59-59-449.png     PNG File image-2021-04-15-18-00-34-701.png     PNG File image-2021-04-15-18-00-40-664.png     PNG File image-2021-04-15-18-04-07-161.png     PNG File image-2021-04-15-18-07-18-376.png     PNG File image-2021-04-15-18-10-00-823.png     PNG File image-2021-04-15-18-10-41-416.png    
Issue Links:
Cloners
is cloned by MAGNOLIA-8299 Follow-up - DefaultI18nContentSupport... Open
Problem/Incident
Relates
relates to MAGNOLIA-8733 Add Locale variant support to I18nCon... Open
documentation
to be documented by MAGNOLIA-8243 DOC: Explain fallback locale vs defau... Closed
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
As you can see I'm using both for their intended purposes.

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. 
e.g.: 
"/de_DE/" doesn't have content? -> Show the fallback locale (en_GB, in this case).

As the documentation states; 

Content is served for the fallback locale if content is not available for the current locale.

Or as the code states: 
The content is served for this locale if the the content is not available for the current locale.
This part works fine, fallbackLocale is used for a fallback locale

 

Your documentation doesn't show defaultLocale (which just is a matter of missing documentation) 
AbstractI18nContentSupport.class however does use it, and has done so for ages.
The code states: 
If no locale can be determined the default locale will be set. If no default locale is defined the fallback locale is used.

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.
The content within the page can fallback to the fallbackLocale, that's expected behaviour.

Comment by Mercedes Iruela [ 22/Apr/21 ]

Hello Jeffrey,

We discussed the issue internally:

  • We will include defaultLocale in the documentation also.
  • Would you mind to create a PR following our Contribution guidelines

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()`.
See https://git.magnolia-cms.com/projects/PLATFORM/repos/main/commits/b019770b42d0cb6905e007c379c5f5054610db51#magnolia-core/src/main/java/info/magnolia/cms/i18n/AbstractI18nContentSupport.java.

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
Since this is the only change to core I believe you can simply exchange core 6.2.15 for 6.2.14 and it will work in Bundle 6.2.15. I know that's not ideal but it should be ok while we sort this out. At least you upgrade everything else for the meantime.

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

Generated at Mon Feb 12 04:29:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.