Full path not being created for other-language pages

[yankl]

This commit, in release 2.0.0, seems to cause a regression for me.

When on the default language on a certain page, a link to a translated language (in this case English), would previously be output as /en/kapitl1/lektsye1/kultur. However, now it's being output as /en/kultur. Namely, the intermediate folders between the root and the page folder are being omitted.

I've confirmed that when I change the line in twig from {% set lang_url = base_lang_url ~ langswitcher.translated_routes[language] ~ page.urlExtension %} back to {% set lang_url = base_lang_url ~ langswitcher.page_route ~ page.urlExtension %} the regression is fixed. Beyond that, though, I haven't yet figured out what the issue is.

[godfatherjohn]

I cannot reproduce this. A dumb question on my part, has your 'kultur page' a routes: default: /kultur set?

What does your link to the translated page look like? Is it static or dynamic?

My setup: Grav 1.7.35, Langswitcher: 2.0.1

[yankl]

You're talking about a setting on the .md page, right? No, there's no routes: in the frontmatter.

I'm afraid I don't understand your second question. The link to the translated page is generated by the langswitcher plugin here.

I'm also on Grav 1.7.35, Langswitcher: 2.0.1, and you can see the actual broken link here.

[godfatherjohn]

Do you have a global route set in the backend -> Configuration -> Site (tab) -> Redirects & Routes?

I have built several multi-lingual websites but have never experienced this issue. Are you sure that your setup is neat and in good order?

On the question how the link behind the button is implemented. So you have customised the appearance (CSS) of the Langswitcher frontend section? What originally would simply be Hebrew English on your page, is now a bit further apart and insinuates two 'language buttons'? Is that correct?

In any case, I still believe that the issue is not down to Langswitcher but rather to something else.

As a workaround, you could implement links in this way:

{% set about_url = pages.find('/more/about').url|e %}
{% set about_menu_name = pages.find('/more/about').menu|e %}
<a href="{{ about_url }}"> {{ about_menu_name }} </a>

This automatically links to the right About page. If you are on the HE version of your site, you will be taken to the About HE version. If you are on the EN version, you will be served the About EN version.

NOTE: Your page's links in the footer section, all three of them, send the user into an error message. This would buttress my assumption that something is flawed with the setup rather than Langswitcher.

[yankl]

Hi @godfatherjohn, I appreciate you looking into the specifics of my site.

I have no routes set up in my site.yaml config file.

It's true that I've used CSS to customize the appearance of the language switcher links, but the HTML is still being created by the plugin, and missing the containing folders:

<ul class="langswitcher">
  <li><a href="/kapitl1/lektsye1/kultur" class="external active">ייִדיש</a></li>
 <li><a href="/en/kultur" class="external">English</a></li>
</ul>

I'm not sure how to confirm that everything else with my setup is in order, but I haven't noticed any other problems with links except here, and only since langswitcher v. 2.0.0, and as I mentioned in my original post, the problem is resolved by switching a line of code in the langswitcher plugin back to what it was prior to v. 2.0.0. So my impression is still that the problem is caused by the new way the plugin has of generating the links. (I'm referring to the new function getTranslatedUrl which looks a bit complex to me and not simple for me to debug.) Switching back the line of code in the twig template bypasses this function and creates the link the old way.

The links in my site footer are just placeholders.. my site is still in development and those pages haven't been created yet.

With regards to your workaround, it sounds like that might be a way of linking to same-language pages, whereas what I'm looking to fix is the langswitcher which links to other-language versions of the same page.

Thanks again!

[godfatherjohn]

Hmm, could it be that there are two different langswitcher.html.twig files:

One in /user/plugins/langswitcher/templates/partials And another one in /user/themes/YOURTHEME/templates/partials

?

If that is the case, what happens if you use the vanilla langswitcher.html.twig (v2.0.1) in both folders?

[yankl]

No, langswitcher.html.twig doesn't exist in my theme templates folder, so I believe my site is using the unmodified plugin twig.

[godfatherjohn]

What happens when you set EN as the primary language and HE as the secondary? Theoretically, that should shorten your HE path then.

[yankl]

Ah interesting, I switched to default_lang: en in config/system.yaml, and it did not make a difference on the Yiddish page.. namely, the English link was still missing the folders. But on the English page, it's the Yiddish link that's missing the folders.

So in fact, it seems not to be related to which language is primary: any link to another language, whether that language is default or not, is broken. (This wasn't clear before because my default language is not usually appearing on translated pages due to another bug, #67.)

It's no surprise that the link to the same page you're on is correct, because that url is generated directly from page.url , and so bypasses the getTranslatedUrl function.

So maybe it would be more precise to change the title of this issue to refer to "other-language", not "translated" pages.

[godfatherjohn]

Did you also change the .md file names, i.e. default.md for EN and default.he.md for Hebrew? I'm asking because of that other issue discussed in #50, where the country code in the .md file can cause a change in Grav's behaviour.

It's a (veeery) long shot, but it would be interesting to see what uninstalling Langswitcher > then manually deleting all content in the folder 'cache' > then reinstalling Langswitcher would do.

I haven't done much with PHP, I will try to dig deeper when I have time. I don't know when this will be, though. Something appears odd in the way the path to the page is read in by Grav. The priority should be (from highest to lowest): 'routes: default: xyz', then the slug name, then menu name (as a fall back for the slug), and then the folder name (as a fall back for the menu name.

[yankl]

Actually, after a bit of debugging (thanks debug bar!), I believe I've found the source of the issue.

The problem lies in this line: $translated_md_filepath = "{$path}/{$current_node->template()}.{$lang}.md";

There are, I believe, two assumptions being made in this line, neither of which are correct with regards to my site:

1. Every .md file will contain a language extension. (This is the same assumption that led to #67 )
2. All folders containing an .md file in a given language will also have associated .md files with the same language extension.

Assumption 1 should not be made, as there is a setting of Grav which does not include a language extension for the default language when creating an .md file. (include_default_lang_file_extension: false).

Assumption 2 need not apply in sites, such as mine, where I only have various language versions of a page for some pages.

For instance, my site has the following string of folders: pages contains: kapitl1 folder which contains: the file kapitl.md (only default language, no lang extension), and the folder lektsye1 which contains: the file lektsye.md (only default language, no lang extension), and the folder kultur which contains: files bilingual_default.md (default language, no extension), and bilingual_default.en.md.

I believe this structure is completely valid in Grav, and so should be supported by this plugin.

Once the recursive functions hits a folder where one of the above assumptions doesn't apply, it jumps straight through the rest of the recursion, and exits it without even traveling further down the path.

I'll see if I can fix this simply. That said, it seems to me that such functions as finding the full slug path of a page could be useful in various kinds of plugins, and should be abstracted away to Grav Core, where it's done in the most efficient and correct way possible, instead code in plugins having to keep in mind the various folder/file structures a Grav site might have.

EDIT: I've proposed a PR to fix this: #70

[godfatherjohn]

Excellent news, and an excellent job by you! I think you hit the nail on the head!

Just for better readability, your folders and their contents, and the issue as a whole:

/user
    /pages
          /kapitl1
              kapitl.md
              /lektsye1
                   lektsye.md
                   /kultur
                       bilingual_default.md
                       bilingual_default.en.md 

Yes, this file and folder structure is definitely valid. The problem lies in the path building.

In a nutshell: For secondary languages, Langswitcher is not including a given directory in the path variable, when that directory has no secondary language .md file in it.

EXAMPLE In your browser, you visit the default language page that is in the directory /kultur (Grav internal: bilingual_default.md), and now you want to switch to the secondary language page (Grav internal: bilingual_default.en.md). Upon clicking on the secondary language (in the Langswitcher section on the website), an error appears and no page (or a 404 page?) is served. The reason being that instead of the correct path en/kapitl/lektsye1/kultur/bilingual_default.en.md the false and shorter path en/kultur/bilingual_default.en.md to the landing page is used by Langswitcher.

Workaround: Include a secondary language .md file in each directory.

I agree, it would be good if plugin developers wouldn't have to worry about traversing/building the path.

[rhukster]

Please try the latest version of the 'develop' branch. I've rewritten this logic.

[godfatherjohn]

I confirm that this issue has been fixed. Grav now falls back to the name of the directory if the slug is left empty.

[yankl]

@rhukster Thanks so much for all the work on this! I just tried out the latest 'develop', and unfortunately, while the old bugs have been fixed, yet a new one has popped up. Out of the four links:

On Yiddish (default) page: Yiddish link: /kapitl1/lektsye1/kultur Correct! ✔ English link: /en/kapitl1/lektsye1/kultur Correct! ✔ On English page: English link: /en/kapitl1/lektsye1/kultur Correct! ✔ Yiddish link: /en/kapitl1/lektsye1/kultur ❌

For some reason the link to "Yiddish" on the English page leads to the English page instead of to the Yiddish one.

I haven't studied the new code well enough yet to understand why.

[rhukster]

i'm afraid I can't recreate this. WIth my latest develop branch symlinked in to a local copy of your site (I grabbed it from trilby staging), it works fine:

https://user-images.githubusercontent.com/1084697/185513349-dbd817e7-dabe-4579-aa53-d39f95df48a8.mp4

[rhukster]

Actually i had a hunch it might be related to the the subpath that I have in my testing environment, so i created. vhost for yiddishpop.local so that the site runs at the root (no path to the site), and then I can recreate your issue!

Looking into it now!

[rhukster]

Ok should be sorted now. Just pushed the latest updates to both twig files.

[rhukster]

if all is good, i'll release an update tomorrow.

[godfatherjohn]

@rhukster -- The latest update does fix the regression issue in both of my systems. Thanks a lot!

NOTE: Not mission critical but one little issue has popped up though, the class 'active' ( {{ active_class }} https://github.com/getgrav/grav-plugin-langswitcher/blob/015702e2499263745cfeb41eb45b9cf1b66a7ab2/templates/partials/langswitcher.html.twig#L30 is no longer appearing in the rendered HTML file. Hence, the active language is not highlighted in the langswitcher section on the website. I have this issue on both sites.

[rhukster]

doh stupid error, fixed in develop.

[godfatherjohn]

Yep, it's now sorted. All looking good! Ready for prime time. 👊

[yankl]

At least on my end, seems to be working great! Thanks so much for putting the time into this @rhukster !!