User tests: Successful: Unsuccessful:
Remove default language SEF tag (e.g. "en") from URL in mod_languages helper when "Language Filter" plugin configuration is set to do that (Remove URL Language Code = YES).
This is a proposed fix for Issue #26480.
When building the list of URLs in the existing languages for the mod_languages, strip the default language prefix from the source code in the switcher with a regexpr in the case the Remove URL Language Code setting in the Language Filter system plugin is set to YES.
Create a multilanguage site with English as default language and LANG2, with language switcher module published, SEF enabled and all other stuff to have a multilingual site.
In the Language Filter plugin, set Remove URL Language Code = YES .
Create for example two articles in the two languages and associate one each other.
In front end, go to the article in LANG2 and look at the source link for English in the language switcher module.
With this PR, the URL is without the "en" tag in the URL.
Without this PR, the URL has the "en" tag in the URL even if the option in the language filter plugins requires it to be removed.
Status | New | ⇒ | Pending |
Category | ⇒ | Modules Front End |
To prove my statement go to www.joomla.org/3
If your browser is in english then there is no /en on the url
There is: change the language to non English and then look at the language switcher for English: the link is "https://www.joomla.org/3/**en**/"
I am making a fix on the PR to avoid naming conflict
It is not about what the switcher says it is what the url in the address bar says
Labels |
Added:
?
|
Crawlers read the link in the modules, then yes when they will request that links they will get a 301 redirect to another URL without the tag but why not showing the final URL to the crawlers without having google index to track non-indexed URLs since they get redirected? That's the purpose of this PR :)
I personally got URLs with "en" showing in google results for my sites
Looks like this does not create an issue. Has to be tested in all situations.
For clarity you are referring to the link in the source of the switcher and not the URL in the address bar as a result of using the switcher. That's what I didn't understand from the original description
In fact, there is a culprit.
It breaks the home page switch.
The reason is the cookie set when you switch from another language home page to the default site language home page.
I would close this.
@brianteeman: yes, I didn't specify esplicitly it, I will update the description.
@infograf768: why it would break the home page? It just get rid of the "en" if there is one. I am using also in the home page: should I have to test some specific situations? I am available
A cookie is set. Therefore, when switching, the cookie is used as there is no indication that the language changes. This is why we never implemented that change in the switcher.
It shows only on the home page because we have there a pure domain url.
Here French (fr) is the default site language. I first make sure I display the English home page then try to switch:
The only way it would work is to use the setLanguageCookie($languageCode)
method from the languagefiter plugin and set the cookie to the default lang.
But, evidently, this can't be done in the module helper.
Sorry, I have difficulties in understanding the problem but surely it's my fault. In the case of a site with French as default language, I have a URL=site homepage with switcher flags showing site for French (itself) and site/en/ for English. Same values appear when in the English homepage.
So it's not clear for me the cookie issue, but if you say that we need to set language cookie, we could invoke setLanguageCookie?
`public static function setLanguageCookie($languageCode)
{
$app = JFactory::getApplication();
$plugin = \JPluginHelper::getPlugin('system', 'languagefilter');
$params = new \JRegistry($plugin->params);
// If is set to use language cookie for a year in plugin params, save the user language in a new cookie.
if ((int) $params->get('lang_cookie', 0) === 1)
{
// Create a cookie with one year lifetime.
$app->input->cookie->set(
JApplicationHelper::getHash('language'),
$languageCode,
time() + 365 * 86400,
$app->get('cookie_path', '/'),
$app->get('cookie_domain', ''),
$app->isHttpsForced(),
true
);
}
// If not, set the user language in the session (that is already saved in a cookie).
else
{
JFactory::getSession()->set('plg_system_languagefilter.language', $languageCode);
}
}`
In the switcher module, the language tag is needed so Joomla knows which language it should switch to. Without the tag, it assumes the currently active language based on the cookie setting.
Also, it is architecturally wrong to change the module behavior based on a plugin parameter. So this PR wouldn't acceptable anyway.
I'm going to close this as it is intended behavior and not a bug.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-03-07 19:22:56 |
Closed_By | ⇒ | Bakual |
Hi, of course the boss here is you :) so ok, but just a final comment on this closure:
I got links indexed by Google with the default lang tag instead of actual URL, that's why I was proposing something.
best regards
Yes, I know this is closed but Google sees both urls: with and without the default language prefix, bad thing
Yes, I know this is closed but Google sees both urls: with and without the default language prefix, bad thing
No, it's not a bad thing. It doesn't matter at all.
When the site is large and then it will have a lot of redirects, what then in this case?
Can not confirm.