Route localization attempt based on the translated slugs

[flagar]

Using custom slugs if found through the translated markdowns of the pages hierarchy... this should lead to a better SEO for multilanguage websites

[flagar]

This should fix issue #39. I got the same problem using the sitemap plugin, I submitted there another pull request with almost the same code. Probably the best way would be to have the common code in the Grav core.

[malenkiki]

This fix works on my project, thank you @flagar !

[bitstarr]

@rhukster Please review this, because it's pretty important for SEO. The meta template should also be changed to use this function.

[barbanet]

Reviewing and approving this PR would be very beneficial for the plugin (and for our ability to use Grav for multi-language sites)

[maofree]

why hasn't it been implemented in the real version yet?

[maofree]

Hi @rhukster I've tested this last update 2.0.0 but it doesn't work well, there is a problem with homepage for example if I set the italian language and I pass the mouse hover the english language, its url will have "/home" at the end look at here https://github.com/getgrav/grav-plugin-langswitcher/issues/63

it is missing the x-default language in the header hreflang="x-default"

bye

[yankl]

@rhukster @flagar This PR seems to cause a regression for me, see #69... any ideas?

[godfatherjohn]

Perhaps some important details on this issue reported by @maofree

Important is to note that the issue reported by @maofree, meaning Grav is appending the folder name to the URL displayed in the browser bar when clicking on another language, apparently only happens with the 'root page' (e.g. 01.home) but not with the child folders inside 'home'. At least on my test site.

I have disabled all routes: default: xyz when testing this. I have set slugs for each page: EN and the secondary language

Here is an example

Test preconditions:

• EN is the default language, FR is the 2nd language
• home folder name is '01.home'
• include default language is turned 'off' system wide (and no frontmatter page overwrites are used)

Steps:

1. Access mydomain.com --> EN page version is displayed and URL is mydomain.com
2. Click on FR in the langswitcher section (frontend) --> FR page version is served with 'home' added to the URL in the browser bar, hence it is mydomain.com/fr/home instead of mydomain.com/fr
3. Click on EN in the langswitcher section (frontend) --> EN page version is served with 'home' appended. Hence the URL in the browser bar is mydomain.com/home instead of mydomain.com

NOTE: This issue appears to be exclusive to the 'home' folder, i.e. the websites 'root', often '01.home'. I cannot reproduce this issue with the home folder's siblings.

As said above, I don't have this issue with the child folders inside 'home'. IMO: It is no critical issue and does NOT impact SEO.

UPDATE 1: I have found out that, for the default language, 'home' IS NOT being appended to the domain in the browser address bar if your default language file name DOES NOT contain the country code, e.g. default.md instead of default.en.md. (But 'home' is still appended to the secondary language, which naturally contains the country code in the file name in any case.)

In my tests, I have used the 'Learn2' (Hibbitts Design) and the 'OpenPublishing Space' (Hibbitts Design) skeletons. The issue is the same for both skeletons.

Slugs seems to be neglected when switching back to the default language + workaround

I don't know if this is related to the above but when somewhere on a nested page, e.g. home/sub/subsub, and switching back from the secondary language to the default language, the folder path is shown in the browser address bar instead of the slugs.

However, when clicking on the secondary language again, the slug path is correctly displayed in the browser address bar for the given secondary language. If one switches back to EN, the folder path is displayed again.

HOWEVER: If default.md is named default.en.md, the issue disappears and the slug path is correctly shown in the address bar, for the default language.

[rhukster]

what would really help would be a little package of system config + sample pages so i can easily recreate this issue. my current test sites all work fine.

[godfatherjohn]

@rhukster -- the 'system config' file and everything included in 'pages' ? Before downloading that, would you prefer to have access to my system?

[maofree]

Hi @rhukster and @godfatherjohn

it is necessary to add the x-default language into templates/partials/langswitcher.hreflang.html.twig

before the end line {% endfor %}

instead on the home voice at the end of the url is present on the lang selector

I get the home problem on a website included in a sub-folder, the problem is present only in the homepage for each languages

look at this video https://watch.screencastify.com/v/rnuQBEQ9U5rBjilUkWkW

I've solved this problem with this code editing templates/partials/langswitcher.hreflang.html.twig and templates/partials/langswitcher.html.twig

but a guy said me that it is present a problem with multi-website solution, so it is necessary to add the shop extension

override.zip

the langswitcher.html.twig is changed to us the bootstrap dropdown for the lang selector

[godfatherjohn]

@maofree - I'm not sure if I have understood correctly.

Generally, I cannot really see the point in adding the hreflang="x-default" line to the template, since it is only for pages for which no language has been specified (here more on Google Webmasters).

On adding the line <link rel="alternate" hreflang="x-default" href="{{ uri.base ~ lang_url ~ uri.params }} />, where exactly should this code be pasted in? Which line? I will definitely try it out.

I'm asking because the code in your second screenshot is the entire code from the file langswitcher.hreflang.html.twig and comes with the plugin (here on Github) by default. As such, it is the exact code I use in my setup. I cannot see the hreflang="x-default" tag in there.

In your screencast video, you seem to be in the home directory of your website, is that correct? What is the behaviour when you go to the 'About' page of you site and then switch languages? Does 'home' still come up in the address bar?

[yankl]

@rhukster If it helps, the page I mentioned is actually on Trilby hosting, so feel free to take a look in there -- https://yiddishpop.trilbyhost.com/kapitl1/lektsye1/kultur You can see the link "English" leads to the nonexistent https://yiddishpop.trilbyhost.com/en/kultur, whereas https://yiddishpop.trilbyhost.com/en/kapitl1/lektsye1/kultur would be the correct URL.

[godfatherjohn]

@yankl - Maybe it would be better to discuss the path issue in the corresponding post (#69), to keep things tidy.

@maofree - on the 'home' added to address, I have further looked in this issue. Question for you, does your default language file name have the country code in it, e.g. default.it.md instead of default.md?

I'm asking because I have found out that, for the default language, 'home' IS NOT being appended to the domain in the browser address bar if your default language file name DOES NOT contain the country code, e.g. default.md instead of default.it.md. (assuming IT is your default language). (But 'home' is still appended to the secondary language, which naturally contains the country code in the file name in any case.)

Note 1: that I can still only reproduce this issue for the website's root directory (i.e. the homepage, usually in folder '01.home').

Note 2: In my tests I have used the 'Learn2' (Hibbitts Design) and the 'OpenPublishing Space' (Hibbitts Design) skeletons. The issue is the same for both skeletons.

Could you get back on the question from last night: "In your screencast video, you seem to be in the home directory of your website, is that correct? What is the behaviour when you go to the 'About' page of you site and then switch languages? Does 'home' still come up in the address bar?"

I believe that adding the herflang="x-default" is more of a hack than the real solution. (I might be wrong, though.)

[maofree]

Hi I've edited the previous post it is necessary to edit two files

templates/partials/langswitcher.hreflang.html.twig and templates/partials/langswitcher.html.twig

I've attached a zip override.zip with the two edited files to set into the theme

[godfatherjohn]

@maofree -- - include default language is turned 'off' system wide (and no frontmatter page overwrites are used) in all of my tests. I only change the file name of the default.md, meaning either including the country code or not.

[maofree]

@godfatherjohn that option remove the country code from the default language, in my case the /it/ and it works well the problem is the "home" that appears at the end of homepage url for each urls present in the language selector

the problem is limited only to the homepage, because it is the only page of the site that does not have a slug, for all the other pages there are no problems because the slug variable has a value

I've done a test if I remove the it from modular.md, yes the home will be removed from the url but only from the italian language, and how can I do the same from the rest of the languages?

[godfatherjohn]

@maofree Yes, the unwanted 'home' appendment to the domain is what we are talking about. As said above, the issue appears to be related to the default.me file name. On my two test systems, 'home' is not appended to the domain (of the default language) when the .md file is named default.md instead of _default.en.md_.

Apparently, something got messed up with considering the .md files in a folder and their endings, and this trickles down to adding the 'home' folders actual name to the domain.

Thanks for confirming that the issue is only present on the homepage, not on subpages.

[maofree]

I confirm that if I remove it from modular.it.md the home will remove from the url, but for the rest of languages I continue to get the home

I think the problem is around the slug, in the homepage is void and grav adds home the name of folder

https://watch.screencastify.com/v/rnE50XwvJQOYSxGyOwYB

[godfatherjohn]

"I confirm that if I remove it from modular.it.md the home will remove from the url, but for the rest of languages I continue to get the home"

Further up you were saying it happens with the subdirectories too, therefore it's good to see that this is not the case. Hence we have pretty much nailed down the issue, that should make fixing it easier.

Exactly, because your secondary languages have the country code in the file name (default.COUNTRYCODE.md).

[godfatherjohn]

I think the problem is around the slug, in the homepage is void and grav adds home the name of folder

Nope, the issue persists, no matter if you use slugs or not. But maybe the folder name is read and falsely assigned to the slug variable. It should not be a big issue.

Most importantly, this 'home'-appending issue it is not critical and it does not impact SEO. The home-added domain is not shown in the sitemap either.