Translate-plugin: Add setting to disable retrieving locale from session

[vannut]

For almost all of my projects I want a slightly different use of the routing of the Translate plugin. I found a solution, but before making a PR I want to discuss it here with you.

Current behaviour:

At the moment when you visit an url without a locale-prefix in the url-segments the (new) localeMiddleware looks for the locale stored in the session.

So domain.tld/ will always show the default page in the last visited locale. So if i first visited domain.tld/de and afterwards I would go to domain.tld/ the page would be in German(de).

Desired behaviour

When no locale found in the url::segment(1), just stick to the default locale. Result would be the following:

• domain.tld/ <-- always the default locale
• domain.tld/es <-- alternate locale
• domain.tld/nl <-- alternate locale 2
• domain.tld/en <-- default locale

Solution:

Make the retrieval of the locale from the session optional.

// Current LocaleMiddleware.php L:20
if (!$translator->loadLocaleFromRequest()) {
    $translator->loadLocaleFromSession();
}

Commenting out this if -statement results in the desired behaviour. So I would like to add a setting somewhere which disables this statement.

As we not yet have a settings-model for this plugin I would discuss if we add one. But that might be a bit overkill for just one setting.
We could add a config setting in /config/translate.php which defaults to true (when not found) so we have the possibility to add it when needed....

[vannut]

@datune This adresses your 'problem' with my plugin.

[datune]

@vannut Thanks!

In fact, your described "desired behaviour" is the best practice for multilingual sites. Google and co. also strongly discourages setting site language based on cookies without an explicit domain or uri parameter.

The default behaviour of the Rainlab.Translate plugin is actually a bad practice, especially for SEO.

For those who want to know more: read this

[CptMeatball]

I feel like skipping the session entirely is somewhat of an edge case.

That said, I think it _should_ be possible, but not through backend. I'd favour a settings file over a new settings tab with only two checkboxes. Something like:

Settings/translate.php

/*
*  null => current behavior
*  true => Skip Session / Force URL
*/
`skipSession` => `null`,
`forceLocale` => 'null'

==

@datune By forcing the url locale in the component, the SEO struggles are solved I think. There's an option to force the URL to the session locale.

[Eoler]

Yup, if you're not using hreflang's with immutable locale-specific URLS you better be very very clever if you want to rank...

[datune]

@CptMeatball I know about the "enforce" setting for Rainlab.Translate, the problem with that is, it enforces it for ALL languages, including the default one, which is not optimal.

Consider the following fictional example:
_http://www.some-domain.de_
now always becomes _http://www.some-domain.de/de_

That doesn't make sense, especially considering that most of the time you'll also have domains for specific regions / languages, now all of a sudden all those will always have their already default language added to the domain.

Excluding the default language from the "enforce" setting (to be bc perhaps optional?) should be possible to overcome this. I tried looking into it, via a plugin, but in the end I think it makes more sense to add this to Rainlab.Translate.

[CptMeatball]

Hmm, didn't know this. I thought that the default was absent in this setting. That should definitely be part of this issue, because in the end you want consistency in your URLs.

[vannut]

Jups. That's the problem with the forceLocale=true setting: it enforces it everywhere.

To avoid an XY-problem: In the end we want a solid not-changing by sessions, domain structure.
So the domain without prefixes serves the default locale (That's why it's a default); while all other alternative locales should have their own 'folder' on the main domain.

If i'm reading all this correctly, adding a new config file which holds this setting would do the trick. Off course with sound defaults for when the settings file would be missing. In order for the plugin to behave like before.

[LukeTowers]

@vannut @datune @CptMeatball @Eoler This proposal sounds good to me, somebody please implement it and make a pull request

[vannut]

Will do asap!

[LukeTowers]

Thanks @vannut! @datune @CptMeatball @Eoler could one or more of you test @vannut's PR (#317) and let me know if that works for you so that I can merge it?

[LukeTowers]

Implemented in #318