EE compatibility updates:

  • Publisher is EE5 compatible, but it does not currently support the Fluid field. licenses:

  • If you purchased an add-on from, be sure to visit to add the license to your account here on

Ticket: Language switcher un-translating the translated url_title

Status Resolved
Add-on / Version Publisher 2.10.8
EE Version 5.2.2

Mary Ellen Slater

Apr 26, 2019

mod.publisher.php:375   $languageVar[‘switch_language_url’] = htmlspecialchars($url.’&lang_id=’.$languageId.’&’).$currentUrl;

When browsing this URL: /article/young-woman-fights-melanoma-and-gives-back
The {translated_url} variable for our lang_id=2 produces this url correctly:
We are translating the template article to artículo and the url_title is being translated as well.
That’s all correct.

The language switcher is producing a url with ACT=27, which for us is the set_language function:

When we base64_decode this:
We get the correct URL, with both the PATH and URL_TITLE translated:
But when the browser loads, it places us here:

The content is correctly in lang_id = 2, but the URL title had reverted back to the lang_1 title, even though what was passed was the correct url.

should have been.

When we are returned to this url:
and shown lang_2 content, the language switcher will then generate an incorrect URL for the translation back to lang_id = 1.
Giving us this URL value:
which produces a 404 error.
From that point onward the language switcher function can’t create a correctly path’ed url that doesn’t produce a 404 error.

We’ve found that adjusting the switcher like this works better for our needs (as it translates the PATH as well), but with the same issue, we are losing the translated URL TITLE upon redirect.
$languageVar[‘switch_language_url_custom’] = htmlspecialchars($url.’&lang_id=’.$languageId.’&’).‘url=’.base64_encode(urlencode($translatedUrl) );
Calling it with: {switch_language_url_custom} in our template, and only for the language id that isn’t active (so it’s a toggle).

on this URL: /article/young-woman-fights-melanoma-and-gives-back
shows the switch url as:
however when I click that link, I am brought here:

Why did it translate back the url_title to lang_id = 1 value when the whole page is in lang_id = 2 value?
Without our switcher code change the toggle does not work for our urls, it produces incorrectly pathed urls that throw 404s.

Please advise.  Thank you.


BoldMinded (Brian)

Apr 26, 2019

Thanks again for the detailed report. I’ll try to replicate this locally and get back to you in a few days.


Mary Ellen Slater

Apr 26, 2019

Thank you.  We may not be using this switch correctly, since we are using it as a toggle.
We have 2 languages, if one isn’t active, then it’s the other.
The sticking point for us is that the URL wasn’t correct, so we made that code adjustment from:

$languageVar[‘switch_language_url’] = htmlspecialchars($url.’⟨_id=’.$languageId.’&’).$currentUrl;
to include our custom tag:
$languageVar[‘switch_language_url_custom’] = htmlspecialchars($url.’⟨_id=’.$languageId.’&’).‘url=’.base64_encode(urlencode($translatedUrl) );

Basically using the translated url instead of the current url.

In either case, it’s ignoring the translated url_title, and we are only successful with the adjusted/new tag and not the standard tag.



BoldMinded (Brian)

Jun 30, 2019

I just did some testing and this change _might_ be safe to include in Publisher. As in, {switch_language_url} would use the change you suggested. I can’t 100% replicate the scenario you described, but when testing locally the {switch_language_url} seemed to work fine with your change. I’m going to include this in the Publisher 3.0 release, but if I get but reports of the {swtich_langauge_url} suddenly not working for people, I’ll revert the change.

Login to reply