Links always have the default language in url.

[mhessmann]

Description of bug

After Updating to Evoq 3.1.0 all links has the default language in the url.
In our environment we have Deutsch(de-de) and English (en-gb) as languages configured.

Site Default: English (en-gb)
Enable Language Parameter in URLs: On
Enable Browser Language Detection: Off
Users May Choose Interface Language: Off
Allow Content Localization: Off

Example: Am I on a german page an whant to edit an OpenContent Module,
but the link to the editMode includes the en-GB parameter.
So I have no chance to edit german (de-DE) content.

I found the following commit in the last release, and I think this could be the reason.
https://github.com/dnnsoftware/Dnn.Platform/pull/2607/commits

Affected version

• 9.3.1

[sleupold]

How do your website aliases look like?
There should be a primary alias without a language specified and one primary alias per language.

[mhessmann]

Hi Sebastian, can you give me an example for an alias. I am not sure what you mean.

[mhessmann]

[sleupold]

Marc, please check PersonaBar > Website-Einstellungen > Website-Aliase

[mhessmann]

[sleupold]

Marc,
please make sure, there is only ONE Site Alias marked as primary per language and ONE marked as primary without language!

[mhessmann]

I tried that, without success.

[sleupold]

the problem is the language param in the URL. is the wrong language already in the URL before you try to edit the content? Does this happen just since upgrade to latest version DNN/Evoq 9.3?

[mhessmann]

Please have a look at my first screenshot.
This probleme starts aftert updating to 9.3.0.
And I think this commit is the reason for our problem.
https://github.com/dnnsoftware/Dnn.Platform/pull/2607/commits

[mhessmann]

For building the URL`S this function is used:

Dnn.Platform/DNN Platform/Library/Common/Globals.cs

Line 2915 in 74e86ea

public static string NavigateURL(int tabID, bool isSuperTab)

which is using the changed function:
c0c1300#diff-f8c2cca1f9fcc26f9a7274ab02f96e4dL802

[sleupold]

th problem is the wrong language being passed, but as far as I can see, #2607 tries to avoid this in a different scenario though. The question would be in NavigateURL: is linkTab Null or Linktab.CultureCode? If this method is called for the javascript, this is missing a language and CultureCode should be used from thread.

[zyhfish]

Hi @mhessmann , this looks like has no relation to #2607, is it possible that let me take a look at your site and try to find out the root cause? thx

[mhessmann]

Hi @zyhfish , the problem can be reproduced with a newly installed version DNN_Platform_9.3.2.24. Add a second language after the installation and check the links.

[daguiler]

This happens when you have not yet localized any pages. Try disabling Enable Language Parameter in URLs. Turning this switch off fixed it for me.

[donker]

I can confirm the observed behaviour. And having traced through the code there is something pretty strange that happens.

Globals line 3017: in NavigateURL in the absence of a required locale, the method looks up the locale that is set on the tab.

Then in Globals line 810 in GetCultureCode an attempt is made to find the tab and get its locale. If, like for "User Profile" tab for instance, there is no locale the portal default is returned. PR2607 didn't change this BTW.

I would concur with Jan that this is a bug. Here are my conclusions:

1. It is weird that if no locale is present on a tab then the portal default should be the target.
2. It is lazy that calling code does not specify a locale. In this case: in the code that generates the links to the various pages, why can't the thread locale be passed in?
3. You can leave the locale blank in the NavigateURL method and you'll get a url that has no language parameter set. Rather than assuming the portal default locale should be chosen if the tab doesn't have one, it is entirely possible to leave it blank.

Given that these methods are at the heart of DNN's localisation logic we should be thoughtful about how we resolve this!

[donker]

Found it. This is the commit that changed the behaviour

9ab2276

which aimed to fix this:

#2457

IMHO we should revert that change and figure out another way to solve 2457

[leedavi]

I found this yesterday. I think I can get around this with our clients site by using en-US instead of en-GB. But this is a show stopper for nearly all European clients, can we get a emergency release out soon?

[valadas]

The changes that caused this have been reverted now and pushed to Dnn10 so we can take a better look. This should make it so this current issue is no longer present in 9.4.0. Keep a eye out for 9.4.0 RC and any testing specially for those in this situation is very welcome.