switch default language possible?

[Relmos]

Hi,

I have started a website with default language DE. Second Language is EN.

Now I would like to have EN as default. I already though about redirecting but nothing really seems to make sense/work here.

Would this be possible & and how?

Edit: Not to confuse here: I am talking about the default language on the Front End. Not the users default language in PW as an Editor-Role. So while now domain.com is the default language (de) I'd like to start with domain.com/en/ when you enter domain.com.

Thank you.

- Relmos

[Fokke]

Hi Relmos!

If I remember correctly, you can just switch language for guest user.

[Relmos]

Hi Fokke,

thank you for your answer. 

What do you mean by guest user?

- Relmos

[Fokke]

In admin panel, click Access --> Users.

In this page there is user called guest.

[arjen]

Go to Access > Users > Guest > Select the EN language and hit save. You visitors will see the EN language as default. Use Incognito mode in Chrome to view your site.

[Relmos]

Ah sorry, of course. Thought you were talking about an actual app user here.

But yes, setting default languages for users within pw is possible. But that's not what I meant.

Maybe I should specify my question:

I am talking about the default language in the front end. So when the default lang is DE of course the site will always fallback to DE. But now EN should be the default language. So I am wondering if there is any kind of rewrite I am not aware of so that this is possible in the end?

[apeisa]

when you set the language for guest, it changes it for all visitors that have haven't logged in. I am pretty sure that what arjen and fokke said is what you are looking for.

[Relmos]

Ok, that's new to me, interesting. But then somehow it won't work here (PW 2.3.6). 

When I switch the language for the guest role to EN I get the a success and error message at the same time:

 

And when I visit the site from another computer or at mine without being logged in it's still DE.

Any ideas? Maybe I am missing something cause of the error here?

And maybe I am not really getting the concept of the guest role here. Is it really the guest as visitor? So one that has nothing to do with the CMS itself? Cause a guest role is also defined within roles and permissions. That's a bit confusing.

[arjen]

Should work! You can PM me your credentials and url. I'd be happy to take a look. You can debug echoing $user->language in incognito mode. Are there any files associated with the language?

[Relmos]

Hi arjen,

thank's for your offer here. But I guess that's already what I did and I wouldn't know what else could be configured here. I already deleted all users just to test it, without any effect. By the way the error message I get refers to this post: http://processwire.com/talk/topic/3231-the-guest-role-is-required-error-when-saving-new-user/ So maybe I should update to the latest dev version anyway.

But just to be sure (as now edited in my question) I am talking about the default language on the Front End. Not the users default language in PW as an Editor. This of course if working.

[Soma]

Maybe it would help to clarify what language approach you use and what you expect from saying "default" language. Also what pw version. Just not sure what the thinking here is and it's just there's a ton of factors and also ways to handle language on front end. It's correct that guest user has nothing to do with admin or editor and is just the public not logged in user that visits your site. But depending on how you handle fronted language changing guest user doesn't have any effect unless you explicitly use it for defining language on frontend. In case of LanguageSupportPageNames the language is set by what url you request and the user language set in backend is then ignored. So theres no default language unless you take another approach. Also worth mentioning that default language has its role as it can be used for label and language fields as the fallback value if alternative language has no value. So there's some things to consider when building multilanguage sites. You could also just swop the language packs and rename the alternative language but usually once setup its almost impossible to change everything or becomes a burden as you would need to also change all values of fields and related stuff.

[Relmos]

Thank you Soma for your answer. Here are mine:

PW Version 2.3.6 and I did not yet made any language manipulations except using the language switcher from the Tutorial at MultiLanguage URL.

When I am speaking of "default" language in this case I mean the language that a user sees the first time he enters the domain like domain.com. For now it's DE . I assume that's the case cause I startet PW with DE as the default language using the MultiLanguage URL approach. The second language is EN. Both have a suffix in their URL Structure, like: 

domain.com - root DE

domain.com/de/page

domain.com/en/page

Now I would like any new user to start with the EN version of the site like domain.com/en. 

I added the /de/ suffix cause I though I could them shameless redirect domain.com to domain.com/en. But of course domain.com is the root any redirect wouldn't quite work here. Besides that this redirect is really bad.

In case of LanguageSupportPageNames the language is set by what url you request and the user language set in backend is then ignored. So theres no default language unless you take another approach.

Ah ok. So how would another approach look like? And what then is the real use case of setting a language for the guest user if it doesn't work here?

You could also just swop the language packs and rename the alternative language but usually once setup its almost impossible to change everything or becomes a burden as you would need to also change all values of fields and related stuff. 

That is actually the first thing that came to my mind and the worst I could think of right now

[Soma]

Ok then if you have url segments set for both languages I just would redirect from root domain to what you want the language to be when domain.com is accessed. From there the user is free to change language. I do this in a lot of projects ever since creating multilanguage websites and don't really see why this is bad. Everything fine here.

Only I see problems for in case of pw the default language is used as a fallback and for labeling the admin backend .. so if that's a problem there is no easy way out. but usually also not something that you just change and should be considered well from the beginning.

[Relmos]

Thank's for your quick reply. 

At least I am back on the road that I already though would take me to your statement now. Actually the default language was wisely considered due to the fact that I thought it would be difficult to change it afterwards. But now someone must have pointed the idea at me that the page should start in EN now. Well then...

But while domain.com/de always redirects to domain.com how would I be able to redirect domain.com to domain.com/en then since /de would redirect to /en then?

[Soma]

Hm, there was something going on when Ryan implemented LanguageSupportPageNames about the language segment /de/ /en/ which is something that not really is needed when using this localized urls, but some think it would be nice to still be able to have them. This was when he made "home" page name configurable which normally without this module has no page name. I thought it would be possible to have the default language i.e /de/ be possible, but it looks like it's not, as it will redirect you to "/" root. I've not used this feature since LanguageSupportPageNames came out and wasn't aware, sorry.

I'm not sure what you could do right now but the code that does this is in #294

if($page->id == 1) {
    // special case: homepage
    //$name = $isDefault ? $page->get("name") : $page->get("name$language");
    $name = $isDefault ? '' : $page->get("name$language");
    if($name == self::HOME_NAME_DEFAULT || !strlen($name)) return '/';
    return "/$name/";
}

If you uncomment this line

//$name = $isDefault ? $page->get("name") : $page->get("name$language");

And comment out the line 

$name = $isDefault ? '' : $page->get("name$language");

This would allow you to redirect and stay there like "/de/" or "/en/". But further more this will also automaticly redirect "/" to the default "/de/" and you can't change it really again. So to make "en" default you would have to redirect again. This might be possible with some hook magic, but this seems rather silly.

Since the line is still there I think Ryan was also unsure what would make the most sense and how to behave for the home page if segments are set or not, and I think some configuration should be possible to define the behavior of the special case. 

[Relmos]

Soma, thank you very much for this detailed answer.

I guess what Ryan did was absolut correct cause this case now is really not the usual one. 

So I'll tinker around a bit with you suggestion.

Maybe an option would be to really have control within the settings of the guest role using LanguageSupportPageNames in the end and add this to the feature list.

[Soma]

I'm not sure "guest" user has or should have anything to do with default language! (but maybe it could (?)) As said when using LanguageSupportPageNames, the front end language is controlled via the requested url and not the user language set in the backend. So if you access site with /de/somepage/ the user language is set to "de" (or whatever this is) and the system spits out all stuff in this language: page values, urls etc. Regardless of the pw user's language.

Also worth mentioning that "default" is something that you can define what language that is, so you can easily set default to be german and throw in the language pack on the "default", so default is what you make it.

BUT, I'm really not sure what the best option would be for this special case of the "home" page, but surely not something that doesn't let me control it. I wasn't really aware that the module makes assumptions and redirects me to "/" when I access "/de/" (being the default language). It should be possible to go to /de/ and actually stay there. So some configuration on this behavior would be welcome. So I could do my own redirect from "/" to a language I wish. Or maybe control it simply by being able to define one of the languages as the default? (I'm sure this might as well not easy possible the way Ryan implement all this)

I think Ryan is still ear to such stuff as he's also not so experienced with languages and it should be possible to adjust those things to better suit what people need. 

[Relmos]

Hm, I tried some now. But still I haven't found a solution..any ideas left?

[Relmos]

Still on it...

Another idea: How would a simple redirect within PW from domain.com (index.php) to domain.com/en/ work?

[Relmos]

Ok now I am really at the point of just manually switch the content of every field..

[Soma]

Sorry @relmos, I have no solution and wonder why Ryan hasn't seen this yet.

If you going the route with switching languages, there's also a way to make it by script if it's too many pages. Let us know so we can provide an example.

Also considering other way, it would be possible to add another language "de" and ignore "default". But this would have the effect of still showing the default input for language fields. Also "default" has its purpose as when creating a page it is required to be filles, and as a fallback if no other language values are set.

[Relmos]

Hey, I just went the route to switch the language fields manually now. Took me about an hour, so everything is fine now. 

I red something about scripts too that would make the switching possible but the time to set up one would take the same to just do it manually I guess.

I mean in the end it was my fault not set englisch default at first place anyway. It's a .com domain so de just didn't make any sense here.

So learned my lesson. PW is so great in many ways (thank you ryan!) and it already saved me such a great amount of time that this one more hour is totally fine.

But yes, if there is still something to say about this topic of course I'd be very interested. 

[ryan]

Sorry for not finding this discussion earlier. It sounds like the issue is already resolved, but I'll just add a couple minor points. 

Multi-language support is something that is installed by modules rather than something that's in the core from the beginning. As a result, the "default" language is the one you would have if you had no multi-language support installed. Likewise, the content of the default language is the content that would remain if you later uninstalled language support. So you need to think of that default language as the foundation or core language of the site. Once you start using multi-language fields, you can't easily swap in another language as the default (at least not without copying/pasting or making a little scripts to move things for you). If you needed the ability to do that, then you'd probably want to consider your 'default' language as unused on the front-end, and delegate all of your languages to non-default languages. I think it would be perfectly fine to consider the "default" language as "no language". When editing a page, you'd still be left with placeholders for the default language, which you'd probably just consider to be notes for the admin.

The default language homepage is always represented by the root URL, "/", regardless of what name you've given it in the homepage settings tab. This is to ensure that a user arriving at your homepage doesn't encounter an immediate redirect to /en/ or /de/ or the like. Redirect from homepage is a behavior frowned upon by search engines, and generally considered a bad practice regardless. So ProcessWire is coded to prevent an automatic redirect from occurring on the homepage. That default language name comes into play on the rest of the pages in your site. If you wanted your homepage to be nothing but a language gateway (with no default assumed) then you'd need to delegate your real default language homepage to a separate page, like /en/welcome/ or something like that, which your language switcher can link to.

[Soma]

I completely see and agree, but I think i wasn't too clear with what the current behavior is wrong.

There's no difference from redirecting from "/" to "/en/" than from "/en/" to "/". But currently I can't redirect from "/" to "/default/" as that would give me a endless re-redirect. I think it should be to the developer to decide whether he want the one or the other. (This of course would be when there's a "home" page name for default language defined.)

Sorry if I completely missed the point

[Soma]

Bump previous post?

Currently I need to have default language segment, "de" is default and I want to use "/de/", but I can't because of this redirect to "/" for default language.

Futher, I'm experience a "bug" when using url segments on home template if I go to "http://domain.ch/de/segement" I get redirected to "http://segment/" !

And when going to "http://domain.ch/segment" I get redirected to "http://segment/" too.