[MAGNOLIA-8299] Follow-up - DefaultI18nContentSupport wrongly forwards to fallback locale as opposed to default locale on sub pages Created: 02/Feb/22  Updated: 23/Oct/23

Status: Open
Project: Magnolia
Component/s: i18n
Affects Version/s: 6.2.15
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Mercedes Iruela Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: maintenance
Remaining Estimate: Not Specified
Time Spent: Not Specified
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
clones MAGNOLIA-8065 DefaultI18nContentSupport wrongly for... Closed
Template:
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
Epic Link: Support
Team: DeveloperX

 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: 


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