grav-plugin-langswitcher
grav-plugin-langswitcher copied to clipboard
Session storage "traps" user in a language
Context
I have a site set up so that English is the default language and French is a second language.
When the user switches to French, /fr/
is inserted just after the root me.net/page
-> me.net/fr/page
.
With session_store_active : false
this behaviour works as expected both ways, changing language will add or remove the /fr/
appropriately.
Issue
However, setting session_store: true
"traps" the user in French: trying to change the language to English points the user to me.net/page
as expected but a 302
redirect bounces them back to me.net/fr/page
.
Changing just the session_store
setting and nothing else makes this behaviour systematically repeatable.
Useful data
# /user/config/system.yaml
# ...
absolute_urls: false
default_locale: null
reverse_proxy_setup: false
custom_base_url: ''
intl_enabled: true
session:
enabled: true
languages:
supported:
- en
- fr
include_default_lang: false
translations: true
translations_fallback: true
session_store_active: true # <- Flip this boolean to replicate
http_accept_language: true
override_locale: false
0: en
1: fr
pages:
redirect_default_route: false
redirect_default_code: '302'
redirect_trailing_slash: true
# ...
# /user/config/plugins/langswitcher.yaml
enabled: true
built_in_css: false
untranslated_pages_behavior: none
<!-- /user/themes/custom-theme/templates/partials/langswitcher.html.twig -->
{% for language in langswitcher.languages %}
{% set show_language = true %}
{% if language == langswitcher.current %}
{% set show_language = false %}
{% set lang_url = page.url %}
{% else %}
{% set base_lang_url = base_url_simple ~ grav.language.getLanguageURLPrefix(language) %}
{% set lang_url = base_lang_url ~ langswitcher.page_route ~ page.urlExtension %}
{% set untranslated_pages_behavior = grav.config.plugins.langswitcher.untranslated_pages_behavior %}
{% if untranslated_pages_behavior != 'none' %}
{% set translated_page = langswitcher.translated_pages[language] %}
{% if (not translated_page) or (not translated_page.published) %}
{% if untranslated_pages_behavior == 'redirect' %}
{% set lang_url = base_lang_url ~ '/' %}
{% elseif untranslated_pages_behavior == 'hide' %}
{% set show_language = false %}
{% endif %}
{% endif %}
{% endif %}
{% set active_class = '' %}
{% endif %}
{% if show_language %}
<a href="{{ lang_url ~ uri.params }}" class="navbar-link language-selection">{{ native_name(language)|capitalize }}</a>
{% endif %}
{% endfor %}
I have the same problem.
My website is French and English. I did choose “include_default_lang: true” so the /fr doesn’t appear, only /en for English content.
I wanted to activate “http_accept_language: true” so it switch to the language of my visitor. But as soon as I do that my website redirect me always on the /en, the english version.
That what I wanted, as my browser is not in French. But when I click on the French language link to see the French content, I’m still being redirected to English.
I manage to make it work by putting “include_default_lang: false” and having the /fr in the url.
I didn't find a way to use "include_default_lang: true" and "http_accept_language: true" together.
@agryson Does this happen only on clicking the lang switcher or if you attempt to change url via the browser url bar too? Just in case it's not a plugin issue but a Grav issue
@agryson Does this happen only on clicking the lang switcher or if you attempt to change url via the browser url bar too? Just in case it's not a plugin issue but a Grav issue
Attempting to change url via the browser works.
I'm also running into this issue and exactly like the op determined, session_store: true
seems to be the culprit of this behaviour, in combination with include_default_lang: false
.
The langswitcher templates follow the include_default_lang
system setting, by using grav.language.getLanguageURLPrefix()
, which then leaves out the default language, causing Grav to revert back to its stored language.
So I think the fix could simply be to always include the language instead of using getLanguagePrefix()
. The drawback of that however, is that it triggers an extra request due to the 302 redirect.
P.S. For reference, it looks like #12 described this same issue.
Can this be tested with latest develop branch? that logic has been rewritten.