[MGNLDEMO-66] Tour page only displays english Created: 19/Jun/15  Updated: 12/Mar/19  Resolved: 22/Jun/15

Status: Closed
Project: Magnolia Demo Projects
Component/s: None
Affects Version/s: 0.5
Fix Version/s: 0.5

Type: Bug Priority: Critical
Reporter: Christopher Zimmermann Assignee: Christopher Zimmermann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6263 Locale is always set to fallback loca... Closed
relates to MAGNOLIA-7478 DOC: locale aware virtualUriMapping Closed
causality
is causing MSITEMESH-53 Error 404 when changing language Closed
dependency
is depended upon by MGNLDEMO-36 German translation for content Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled

 Description   

The tour page does not display in german, not just the tour but the navigation and footer, and all the links on the page do not contain a locale part ("/en/" or "/de/").
The locale is incorrectly set to "en" which is the fallbackLocale.
I18nContentSupportFilter sets the locale. (In the aggregationState).

Here's what happens when tracing a request to the page:
1. I18nContentSupportFilter runs and sets the aggregationState locale correctly based on the incoming url:

/de/tours/magnolia-travels/Vietnam--Tradition-and-Today.html

It then REMOVES the locale from the url and stores this "clean" url to the currentUri on the aggregationState.

2. Then RegexpVirtualURIMapping (VirtualUriFilter) runs and maps the currentUri (which at this point has no locale) so

/tours/magnolia-travels/Vietnam--Tradition-and-Today.html

=>

/travel/tour?tour=magnolia-travels/Vietnam--Tradition-and-Today

3. The mapping is configured as a forward, but still this causes the I18nContentSupportFilter to run again. This time on the currentURI:

/travel/tour

Finding no locale in the URI, the locale is set to the fallback locale.


Ideas for fixes:

  • Perhaps the I18nContentSupportFilter should only operate once per request. By its design - it is broken if it gets run again since it has stripped the locale from the string that it will try to operate on again.
  • Change or create a new RegexpVirtualURIMapping that appends a locale?

Ideas that dont work:

  • Perhaps DefaultI18nContentSupport#onDetermineLocale should use the original URI (getOriginalURI()) rather than the manipulated AggregationState.getCurrentURI() as the url to determine the Locale from. DOESNOTWORK in multisite because the sitename is in front of the the locale name and so the locale is incorrectly determined.
    (Or we could create a new one that does this for the purposes of the demo.)


 Comments   
Comment by Christopher Zimmermann [ 22/Jun/15 ]

Fix commited:
Added a bootstrap to add a Bypass to the i18n filter on forward requests, so that the correct locale does not get overwritten when the VirtualURIFilter performs a forward but the URI no longer contains the locale.

Creating linked ticket on MAIN to evaluate whether this bypass should always be in place.

Generated at Mon Feb 12 05:15:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.