While scratching my head about why some Urls were coming out a bit weird when on a page with a translated version, I found out that there is some invalid parameter combinations being passed into the Friendly Url Provider API.

The above screenshot shows the parameters passed into the Friendly Url Provider via the DotNetNuke.Common.Globals.NavigateUrl (tab, path, pageName, portalSettings ) method overload. This particular call is for a Netherlands language translation of the current page, and is the linked Url for the nl-NL flag on the page.

In this example, this was the values provided: tab : tab object for TabId 61, tabPath of //TestPage path : ~/Default.aspx?tabid=63&language=nl-NL - the raw Url for the translated page, which is Tabid 63 page : /default.aspx (normal) portalSettings : current portal settings. You can see the current portal settings are for culture code en-US The problem is that the path (?tabid=63&language=nl-NL) don't match the supplied Tab object (tabid 61, culture= en-US). I think it shouldn't be valid to provide a path for one tab, and then provide the tab object for another.

I belive the problem lies in the TabController.GetTab(tabid,portalid, ignoreCache) call, which underlies the LanguageTokenReplace(newLanguage) call, via the NavigateUrl call.  The problem is in this line (TabController.GetTab, line 703)

' if we have the PortalId then try to get the TabInfo object
                If PortalController.GetPortalSettingAsBoolean("ContentLocalizationEnabled", PortalId, False) Then
                    tab = GetTabByCulture(TabId, PortalId, LocaleController.Instance().GetCurrentLocale(PortalId))
                Else
                    tab = GetTabsByPortal(PortalId).WithTabId(TabId)
                End If

Because the 'contentLocalizationEnabled' value returns True, then the tab is retrieved by the tabid, portalId and culture.  However, because the current locale returned by 'GetCurrentLocale' is en-US, then the wrong tab is returned, which ends up in a mismatched tab object and path being sent to the Friendly Url Provider.

The fix is either to change the NavigateUrl call to find the Tabid based on the Language parameter using GetTabByCulture when Language is supplied, or to
create a new overload for GetTab where the language can be supplied when checking for a contentLocalizationEnabled setting.  For the purposes of language switching, you shouldn't rely on the current configured locale, because you want to find the Url for a different locale to the one you're currently in.

Let me know if this needs to be put in Gemini, or if anyone has any other thoughts.  I don't think 5.5 should be released like this, because it will start to create legacy Urls for future upgrades that will be hard to fix up.

yes, this is a slightly different problem - because it affects the language switching, not necessarily language parameters in the Url.  What you end up with is the wrong Url for the translated language page.

I will wait for the next Beta and see what happens.

From my testing the tabid always changes.  Each translated tab has a master (original language) and associated translated versions.  When you switch from each tab (master->translated1, translated2) the Url changes to match the tabId of each of the translated.  Note it has to be this way because there is no special handling in the Url Rewriter to determine which language a tab belongs to.

In my example 61 is the en-US and 63 is the nl-NL.  The problem is that the path is for 63 but the Tab object is for 61, because the tabobject is retrieved by TabId, portalId and language, and the language is en-US.   WHen you ask for tabid 63, portal id 0 and language nl-NL you actually get back tab 61.

What happens because of this is that the Url drops the tabname part of it : so tabname/tabid/61/language/en-US/defualt.aspx becomes tabid/63/language/nl-NL/default.aspx - this is because of the tabid in the path not matching the tab object.