Coder Social home page Coder Social logo

Comments (22)

yankl avatar yankl commented on July 21, 2024 1

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.

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024 1

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

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024 1

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.

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024 1

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

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024 1

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!

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024 1

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

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024

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.

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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.

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024

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!

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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?

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024

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

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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.

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024

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

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024

@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.

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024

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:

CleanShot.2022-08-18.at.17.39.11.mp4

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024

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

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

@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 }}

<li><a href="{{ lang_url ~ uri.params ~ (uri.query|length > 1 ? '?' ~ uri.query) }}" class="external {{ active_class }}">{% include 'partials/langswitcher-' ~ display_format ~ '.html.twig' %}</a></li>
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.

from grav-plugin-langswitcher.

rhukster avatar rhukster commented on July 21, 2024

doh stupid error, fixed in develop.

from grav-plugin-langswitcher.

godfatherjohn avatar godfatherjohn commented on July 21, 2024

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

from grav-plugin-langswitcher.

yankl avatar yankl commented on July 21, 2024

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

from grav-plugin-langswitcher.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.