November Happy Hour will be moved to Thursday December 5th.

Page shortcuts are bypassing browser language preferences

Vote:
 

Hi all

We're adding multilanguage support in our Episerver website. Some special constraints we have:

  • We don't have dedicated host names for the different languages we will support. All of them will be under company.org
  • We need to detect user browser's language preferences. If we don't have available content for the requested page in the preferred language, we go for the fallback / master language

After reading a lot of documentation we managed to make it work in most cases, but I've encountered an issue with EPiServer shortcuts that is bugging me...

In a non-multilingual scenario, consider a page called 'site-area', configured as a shortcut to a child page called 'home' so that when I navigate to company.org/site-area I'm redirected to company.org/site-area/home.

Going to a multilingual scenario, we translate both the 'site-area' and 'home' pages to spanish (es). Both english and spanish language versions are now created for both pages.

Master language and fallback language is english. No culture is set for the host in website settings. strictLanguageRouting=false in web.config. My browser language preferences are set to spanish (es).

In this scenario, when I navigate directly to these urls I see the contents in these languages:

  • company.org/en/site-area/home --> english
  • company.org/es/site-area/home --> spanish
  • company.org/site-area/home --> spanish (because of browser detection).

So far so good. Now let's see how the shortcut works...

  • company.org/en/site-area --> redirects to company.org/en/site-area/home (english)
  • company.org/es/site-area --> redirects to company.org/es/site-area/home (spanish)
  • company.org/site-area --> redirects to company.org/en/site-area/home (english)

The last case is what puzzles me... I expected to be redirected to the spanish version of the child page, since that's my browser preference. Instead, it looks like episerver completely bypassed my preferences and instead went on to the master language.

I've also tried disabling the fallback language for both site-area and home pages, but since the master language is still english, I guess it has no effect.

Have anyone else experienced this issue? Am I missing something here? Is this a bug?

Thanks in advance!

#211166
Edited, Dec 18, 2019 20:42
Vote:
 

Could you describe exactly how you've added this shortcut?

#211183
Dec 19, 2019 8:19
Vote:
 

Thank you Tomas!

Yes. I've created it using the shortcut propery in the Settings tab, as described in the link below (Scroll down to Settings > Shortcut)

https:// webhelp.episerver.com/17-4/cms-edit/all-properties-view.htm

(Sorry I cannot add images or hyperlinks here...).

Step by step:

  1. Switch to english site in the 'Sites' tab above the page tree
  2. Create a new page of type Site Area (this is a custom type in our website, inheriting from PageData) inside root folder, call it 'Site Area'. Publish.
  3. Create a new page inside Site Area, call it 'Home'. Publish.
  4. Edit the Site Area, go to Settings tab > Manage shortcut. Use these options:
    1. Shortcut type: Shortcut to another content item
    2. Open in: Open the link in the whole window
    3. Internal shortcut: Select the 'Home' page created before.
  5. Save the changes in the shortcut and Publish the Site Area page.
  6. Switch to other site language (spanish in my case) in the 'Sites' tab above the page tree
  7. Edit the Site Area page. With the Languages gadget, create the spanish version by duplicating english content. Publish.
    1. By the way, notice that the shortcut setting has not been copied from the english version, despite of not being a globally shared property.
  8. Edit the Home page. Same as above, create the spanish version by duplicating the english content. Publish.
  9. Edit the Site Area page again, and go to Settings > manage Shortcut. Use the same settings as step 4.
    1. Notice that, when selecting the 'Home' page from the page tree in the dialog, you don't need to select any language version, just the page. Since we're editing the spanish version, I assume that the version that episerver chooses is the spanish version too, as it would made sense and it's available for us. Maybe I'm wrong and this is closely related to the issue!
  10. Save the changes in the shortcut and publish the spanish version of the Site Area page

That's it. With this setting, and having the browser configured with spanish as my first language preference, navigating to company.org/site-area redirects me to company.org/en/site-area/home, instead of the expected company.org/es/site-area/home

Hope it helps. Thanks in advance!

#211192
Edited, Dec 19, 2019 14:56
Vote:
 

Hi again.

So, after more investigation and test on Alloy site I've found out the actual out-of-the-box behavior.

I think the whole point here is that I've set the strictLanguageRouting to false, because we don't want to force all urls to have the language segment, for business reasons.

Having disabled that, I've not found official documentation about the behavior with urls that don't include the language segment, like company.org/page for instance, but it seems that episerver completely bypasses the browser language preferences in this case scenario.

So, in the end, the browser language preferences apparently work for the start page only. The start page contents are correctly displayed in the browser preferred language, and all the links inside include the preferred language segment.

But if you access directly to a page by typing the url in the address bar instead of navigating from the start page, and you don't provide the language segment in the url, then the browser languages preferences are not taken into account, and the content is displayed in the default language. Where is taken this default language from? I'm still investigating...

Cheers

#211224
Dec 20, 2019 12:29
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.