Unable to navigate to a page by their translated url

[lunfel]

I have recently updated an octobercms site from V1 to V3. Now the migration is almost complete, but there is one thing I am not able to fix as of right now and it is the translated url for the pages. Since the translations are now based on the new multisite concept, it seems that the url translation feature does not work anymore.

I have a page setup like so

url = "/historique"
layout = "default"
title = "Historique"
is_hidden = 0
meta_title = "Historique"
meta_description = "Historique"
robot_index = "index"
robot_follow = "follow"

[viewBag]
localeUrl[en] = "/history"
seo_title = "Historique"
seo_description = "Historique"
robot_index = "index"
robot_follow = "follow"
==
(...)

So I expect that I can naviguate to /fr/historique and /en/history, but this is not the case. /en/history will return a 404, but /en/historique will be english translated page I would expect to be served from /en/history.

At the bottom of my site, I have a locale switcher which shows both languages.

[sitePicker]
==
{% for site in sitePicker.sites %}
{% if site.code == this.site.code %}
{{ ('languages.' ~ site.code) | _ }}
{% else %}
<a href="{{ site.url }}">{{ ('languages.' ~ site.code) | _ }}</a>
{% endif %}
{% if not loop.last %} | {% endif %}
{% endfor %}

Here is my multisite configuration

If I am on the /fr/historique page and that I click to switch to english, the url to which it will switch is /en/history, which leads to a 404.

Running the app on the debugger, shows that it is actually trying to translate the 404 page url.

My understanding is that the octobercms route does not have the custom url registered, so it is falling back to the 404 route.

Here are the plugins I have on my site

Plugin	Current Version	Latest Version
Blog	1.7.1	1.7.1
MailChimp	1.0.5	1.0.5
Sitemap	1.2.7	1.2.8
Translate	2.2.10	2.2.10
User	3.1.3	3.2.0
Drivers	2.0.1	2.0.1
Google Tag Manager	2.0.1	2.0.1
Fencus Google Maps Widgets	1.0.7	1.0.7
SEO Manager	5.0.6	5.0.6
Twig Extensions	2.0.5	2.0.5
Simple Contact	2.0.3	2.0.3

I suspect my problem is related to this issue #298

I have also read and applied the migration guide

What am I missing to fix this problem?

[flyingbaba]

Having the same issue with build: 3.7.6, trying to find out the cause.
Other site running on 3.7.1 have no issues.

[lunfel]

@flyingbaba I assume with build 3.7.6 you are talking about the version of OctoberCMS? Do you recall if you updated your version of the translate-plugin at the same time? What what was the version of translate-plugin before and after you updated?

I want to try to narrow it down and find the bug myself if possible.

[flyingbaba]

@flyingbaba I assume with build 3.7.6 you are talking about the version of OctoberCMS? Do you recall if you updated your version of the translate-plugin at the same time? What what was the version of translate-plugin before and after you updated?

I want to try to narrow it down and find the bug myself if possible.

Yes, I meant the OctoberCMS version.
Translate plugin version is the latest : 2.2.10

But actually I found the issue and right now it is working as expected.

My issue was related to EN language because at first I set the Locale to English - Great Britain, and with http://localhost/en - I could not access it. Changing it to English United States helped and right now it is working as expected with /en url prefix. I guess in case of English GB I should use the /en-gb prefix. Now sure, not tested. But with other locales like: /lt /lv it is also working fine.

[flyingbaba]

@lunfel btw, I got a very good advice from another source to have no locale prefix at the default language. (/fr) in your case. All other langs might have them if no custom domain is used.
I have a project I was migrating from v1 and it had prefix on a default language, in v3 I had to write a massive Middleware to handle edge cases for it, like displaying homepage without default prefix (to avoid redirect on a homepage (SEO recommendations)) or having too much 301 redirects from all non-prefixed pages to /en and then again to 404, because spammers were attacking all urls and they were getting into the Search Console etc.