Multilang routing / redir

I have a multi lang website, now found a strange behavior. Let’s assume I have 2 languages CS and EN. CS is set as default. Folder structure is in EN, CS version of the folders is solved via slugs. On a blog, I have only one language in the folder (blog_item.cs.md is the only one file in the folder)

the expected result should be /cs/blog/stranka.html. I found that page is directly accessible via the en version as well /en/blog/stranka.html - and it displays CS version of course - what I expect here is redir to the proper lang route or 404.

This route is not visible anywhere (menu, lang switcher, sitemap,…) I’m not sure how it was possible for the search engine to discover this page - but it is accessible.

A possible workaround is to create blog_item.en.md with published: false (and redir optionally), but I have thousands of articles :frowning: here is the sample of the actual folder structure

user/pages
│           
├───05.learn
│   │   default.cs.md
│   │   default.en.md
│   │           
│   ├───03.blog
│   │   │   blog_list.cs.md
│   │   │   blog_list.en.md
│   │   │   
│   │   ├───aktualni-bezpecnostni-zranitelnosti-procesoru
│   │   │       blog_item.cs.md
│   │   │       
│   │   ├───azure-backup-explorer
│   │   │       blog_item.cs.md

in this folder structure page “aktualni-bezpecnostni-zranitelnosti-procesoru” is directly accessible via url:

cs/novinky/blog/aktualni-bezpecnostni-zranitelnosti-procesoru

  • which is correct

en/learn/blog/aktualni-bezpecnostni-zranitelnosti-procesoru

  • which is incorrect as there is no .en.md
  • route is in EN - this is fine

my expectation is:

  • if lang file not found, fallback from en/learn/blog/aktualni-bezpecnostni-zranitelnosti-procesoru to cs/novinky/blog/aktualni-bezpecnostni-zranitelnosti-procesoru (redirect_default_route)
  • or display 404

The question should be How to make a page available via single route if there is only one language file in the folder

when checking debug, page route and the raw route is displayed as the page exists in EN as well. Lang config is as follow:

languages:
  supported:
    - cs
    - en
  default_lang: cs
  include_default_lang: true
  pages_fallback_only: true
  translations: true
  translations_fallback: true
  session_store_active: false
  http_accept_language: false
  override_locale: true
pages:
  redirect_default_route: true
  redirect_default_code: '301'

Any ideas?

I assume routing is always done in the Grav core, not in the template.

EDIT: tested on clean Grav 1.6 and 1.7 installation - behavior is all the same.

@ondrejv, I’ve been able to replicate the behaviour you are seeing, but haven’t been able to solve it (yet)…

Searching on https://githutb.com/getgrav/grav yielded a similar issue: Disabling translation fallback does not work #2517

In Grav 1.7 there seems to be a new (currently undocumented) feature content_fallback:

languages:
  ...
  content_fallback:
    cs: cs
    en: en

When you now try to access an untranslated page, you should get a 404.

Unfortunately, the blog page for English still shows an item for untranslated pages… I have created a new issue for this.

Thanks, is there any chance to get fixed in 1.6 as well? shall I raise a ticket on the git?

@ondrejv, In the issue I’ve created, you could ask the devs if there will be a backport.

Thanks, as a workaround I’ve created a simple plugin to solve this issue with minimum effort and almost no performance hit. If anyone interested https://github.com/ondrejvysek/grav-plugin-pagelanguagerouter

Not including in the Grav gallery as it is quite specific.

That’s a neat little plugin! May I just suggest one small improvement?

In your code it is assumed that the config file has a variable named reroutecode but it hasn’t. So there are two possible solutions:

  1. the default value “301” is added to the pagelangrouter.yaml file: reroutecode: 301
  2. line #27 of pagelangrouter.php is changed into $reroutecode = $this->config->get('plugins.pagelangrouter.reroutecode', '301');. This ensures that reroutecode is always set even when it’s missing in the config file.

Thanks for the advice, committed update on the git.