Hello community,

I'm having a pair of problems with languages in my site DNN 9.0.0.

It is a multilanguage site (installed es-es, en-gb) and it is just one alias (removed alias with extensions /es-es /en-gb).

Site default is en-US.

Site alias hasn't any language assigned to it.

Enable language parameter in urls is disabled.

Browser language detection is enabled as well as users may choose language.

Content localization is disabled.

I have my own modules using localization.getstring()/localizestring() functions working nice with .resx files

First problem:

Testing pages with a user whose Preferred Locale = es-es / en-GB shows translations correctly ONLY IF pages are not root alias path (www.domain.com/test1 works OK).

However, if I try www.domain.com, localization strings are loading default .resx language, i can see language cookie is rewritten always to en-US for that path.

My browser is Chrome and i'm using Spanish as first language.

The second problem:

If i'm not logged in (cache and cookies cleared), browser language detection is working OK only before I get to the root path.

Root path (again) rewrites my language cookie to en-US, after that, any path i try, will load language cookie = en-US, no longer watching for browser language anymore.

Any help is welcome.

Thanks in advance,

Carlos.

Hi Sebastian,

Sorry, It seems that not the case...

my test:
New fresh install (locally so far) with system default en-US
enable fr-FR, es-ES, de-DE, it-IT
set site-default fo fr-FR (my browser is in en-GB, my college's in es-ES)
deactivate "language parameter in url"
enable "browser language detection" and "users choose interface language"
eliminate all languaje alias, left only root with no languaje specific
create a user (not admin) and set preferred locale in de-DE
create and install own module that shows just a hello in the corresponding language (with resource files for all languages)
create three pages: a, aa, aaa (with one instance of the module, two instances, and three instances)

SET  "a" as home

then, new browser session, go to localhost:2037  -> it shows the site in fr-FR WRONG
type /a -> and display localhost:2037/languages/en-GB/e  (from my browser default) WRONG (becouse the language in the url)
logon and go home, display fr-FR WRONG
go any other page, display in de-DE (my preferred locale) right !!

SET <None Specified> as home

then, new browser session (no cookies, no cache) -> and home shows "a" with my browser default PERFECT ! (but surprise why it still gets "a" as home)
logon, go any page, it shows in de-DE, go home, shows "a" in de-DE , again PERFECT !
go to site settings -> behaviour-> default pages,  and in the home page tab, "a" is still selected WEIRD !! but works

SET anypage as home, save, set "a" as home, save

again back to the wrong behavior

My conjecture:
as any page is set as home, several (two at least) "things" get updated, something in the url parsec/resolver, and something in the page configuration "thing"
as <none specified> is set, one of them (url parsec/resolver) is set to none and that correct the problem, while the other/s (page configuration) still points to "a"

the problem with this, is that the behavior is erratic (we have find some other effects on subpages when the home problem seemed solve)

I do not know what is the perspective of DNN team towards the languages, but something more simpler should be done than whatever is implemented today that keep crashing, I would suggest to remove completely the language from the url and move it to a ?loc= attribute, and define a simple rule to show a portal in a language: first ?loc attribute, second user-prefer-locale, third browser-detection, fourth site-default, fifth system-default. And that's all !!

We are happy to help the community, as done in other cases, 
I could create a public DNN site with reproductability of the error if you wish

Br,

Hi Sebastian,

For SEO issues, and application architecture we decided (and this is a decision that have mayor implications) not tu use .ES / .COM / .UK.CO / .FR / and so on, and relay in browser-detection or main-language.  Or at best, ?loc parameter on a query string.

Our problem so far is with the basic DNN installation delivering the home page on site-default languaje and not in browser detected or prefered local (if user is signed on or not). And I believe this is a DNN bug.