blades

blades copied to clipboard

Any plan to have content multilingual support?

I know blades want to stay dead simple. But multilingual is one of those things that need to be supported at the core otherwise it become messy.

I currently don't have a clear idea how to implement this. Suggestions are welcome :)

I would suggest to use the same structure than Zola or Hugo to allow easier migration. But in term of the actual implementation I have no ideas, I don't know rust much.

I would suggest to go beyond what Zola/Hugo do (which is cram all languages and keys in basically one giant file). It's fine for small sites and a couple languages, but it does not easily scale — especially for translations teams — when you start to have hundreds or thousands of keys in many languages.

@padawan in which way the content translation system of Zola (one file by language) do not scale?

According to https://www.getzola.org/documentation/content/multilingual/ the system is the follow:

content/an-article.md: this will be the default language
content/an-article.fr.md: this will be in French

For the interface translation you indeed have a key system, but that's a very common technics

https://www.getzola.org/documentation/templates/overview/#trans

Gets the translation of the given key, for the default_language, the language given or the active language:

{{ trans(key="title") }} {{ trans(key="title", lang="fr") }} {{/* trans(key="title", lang=lang) */}}

I'm speaking of the site-level configuration, not content at a page level. Here's for Zola: https://www.getzola.org/documentation/content/multilingual/ the first example show all languages being crammed into a single configuration file. When you deal with 10+ langages this is not practical.

(P.S. you say "one file per language", that doc page shows all languages into a single file, which is what I find unpractical. What am I missing?)

@padawan ok got it. Their I can suggestion a general solution perhaps. As the configuration filles use markdown, we may allow subkey to be saved in file named according to the yaml key.

settings.yaml
settings.fr.yaml
settings.languages.fr.yaml
settings.languages.en.yaml

This could be a convention, but I would suggest the logic can simply be to load and concatenate all the file with the following pattern: settings.*.yaml . This mean that even in a file named settings.languages.fr.yaml you still would write the full yaml key inside.