Sorry I forgot to mention that if I de-activate Italian and access the pages directly from the browser, the HOME part of the breadcrumb is correctly retrived (the italian one if I include it-it in the ur and the english one if I include en-us)

Cheers
Gaspare

That is right... in fact Site Settings in Italian I can see and assign the localized version of the page and in Site Settings in English I see the english version. So the registration page in the Italian Site Settings is "Registrazione" and in the English Site Settings is "Register".

At run time the page is correctly served, except for example in the breadcrumb where the home of the current localized version of the website is wrongly calculated (while the current page url is instead the correct one).

I'll try to set up a debbugable version of DNN so that I should be able to trace what is going on with the multi Language engine...

I'll be back with an update as soon as I find out what is causing this behaviour.

Gaspare

Hi again Leupold,
a litte update on this matter with my findings.

The language skin object appers to be the bad guy for messing up languages in the very same page (even if this wrecking behaviour is erratic and usually happens after a while).
What happens is then when the skin objects generates text and links to be rendered on the page it calls the following method at line 282 of /admin/skins/language.ascx.cs:

strReturnValue = LocalTokenReplace.ReplaceEnvironmentTokens(strReturnValue);

When the methods returns, the PortalSettings.PortalAlias is set to the PortalAliasInfo of the CultureCode for which the text/link is being generated by the skin object.

So, just to be clear, I have 2 languages: English and Italian.
I run the website that starts in Italian.
When the language object is rendered, the PortalSettings.PortalAlias is referring correctly to the Italian info.
Then the above method is called for Italian (no change in PortalAlias) and English (PortalAlias is reset to the English information) while all the other values in PortalSettings such as CultureCode, HomeTabId, RegisterTabId, etc. are correctly loaded.

The result is that the other skin objects in the page (i.e. the breadcrumb) is confused when generating the ROOT link because the PortalAlias is the wrong one.

If I modify the above line with:

PortalAliasInfo pai = PortalSettings.PortalAlias;
strReturnValue = LocalTokenReplace.ReplaceEnvironmentTokens(strReturnValue);
PortalSettings.PortalAlias = pai;

everything works like a charm.

Of course this is not a solution, but just a mean to understand what is going wrong. Next step is to understand why the call to ReplaceEnvironmentTokens(strReturnValue) should change the PortalSettings.PortalAlias value.

If you have any hint to shortend the investigation, it will be most welcome.

Thank you
Gaspare