[RFE] - scaffold navigation for translations to allow for upstream management of fallback

[NeilHanlon]

Hi!

Thanks so much for your work on mkdocs-static-i18n. We use this plugin to build https://docs.rockylinux.org and have enjoyed it for the past few years.

Recently we have been working on migrating this site to a new host, and I've been looking specifically at reducing the build time + footprint for the site. To give some context, we have a lot of docs and good coverage of translations for many of those docs, but some who have very few.

When building for locales we have few translations for, the build time is noticeably slower (even on fast hardware) and generates a huge amount of content which is almost if not exactly the same as the default (english) content, save for the navigation menus.

My RFE is for a feature which would work alongside the fallback_to_default parameter and, when set, would build the site's navigation as if all the pages were on disk, but not actually generate the content containing the localized navigation and default-language content.

There are a few obvious flaws I see with this approach--mostly that 'fallback' pages will have a different navigation than non-fallback pages, which means once a user leaves a translated page to a default-language page, they cannot (easily) click to another localized page. Secondly and probably more obviously... the links to these pages wouldn't work!

To address the second point, my intention with this site is to handle the fallback upstream of the static content, and serve the non-localized version of a page if such a page is available (essentially, using logic in our CDN to try multiple paths for a request before giving up).

All that said, I am open to other solutions for this problem, and would be happy to work together on a path which will improve support for large sites using mkdocs-static-i18n.

Best,
Neil Hanlon

[ultrabug]

Hello Neil,

First of all I'm honored to know that this humble project is used by such a nice distro as rockylinux 👍

Can you share some stats of the long build time or anything here for reference? I see from the repo actions that it's 2min per build if I'm correct?

How much faster are you expecting those changes to impact the build time?

Can you confirm that you're using the latest version of the plugin?

I would - if possible - to avoid adding specific options that only a selected few users who can mangle their URLs could benefit from so maybe there's something to be done to get to the acceptable speed you're looking for first (I have a few ideas).

Thanks!