Translations about zola

[bingen13]

Pelican has a lang attribute on the frontmatter of the posts. Posts which are translations of each other have the same slug. When presenting a post, the translations are offered (both on the category/tag/main view and when presenting the post by itself). The post presented by default is the one on the same language as the blog. Not sure what the resolution would be if none of the available languages is that one.

[severen]

See also the alternatives system that Lektor employs, which I use on my own website.

EDIT: My website is currently down due to renovations in my home rendering my server inactive, so if you want to see what the site is like live you'll have to clone the repo and build it yourself. If I get the time I'll set up a temporary GitHub pages mirror, but right now I don't have the time.

[sebasmagri]

From mdBook: https://github.com/azerupi/mdBook/issues/5

[Keats]

I'm almost done with 0.0.6 and I think i18n will be the focus for 0.0.7 so it is time to start thinking about the design!
I've never used i18n on static site engine though so I don't think i'm the best person to design that but I can try given enough sources.
Do any of you know of open-source sites using i18n like @SShrike site? I like the Lektor approach at a glance but it looks like it wouldn't scale past a few languages, too much clutter.

My current thoughts were that any page that needs i18n needs to be in its folder in content, like pages with assets (https://github.com/Keats/gutenberg/tree/master/test_site/content/posts/with-assets). Default language is index.md and users can add no.md, fr.md etc that will get picked up automatically.
That means we need to change the internal linking to take into account the language somehow.

One issue is the _index.md for the sections, I can't figure out how to make those i18n friendly

Any obvious issues with the idea above, other than the _index.md?

[Keats]

Something that would be needed when i18n is added is a i18n filter in Tera that would pull a string from various (yaml?) file in templates like Hugo does, it's not only the content that needs translations.

[Keats]

(this is on hold until there is more feedback from people actually using/wanting i18n)

[batisteo]

As mentioned by @SShrike, Lektor has two ways of dealing translations:

1. It’s called Alternatives and basically the locale is appended to the file name with a plus sign, like _index+fr.md.
2. The second way is called Data Bag – think gettext – and it’s for reusing "components" in a translated page.

I don’t know why Armin used these names, but I like the solution with a suffix (prefix is fine too).

I also used and like Nikola, witch also use a suffix, with an underscore, no folder needed. See my site repo.

The non-obvious part of i18n is also the default language and URLs. Should https://mysite.com/page be https://mysite.com/en/page?

[Keats]

Thanks @batisteo !
The default content should be without a language code imo so https://mysite.com/page.
I can't find a huge static site using i18n so maybe my concerns with having hundred of pages in 4+ languages is exaggerated. I'm leaning towards the name+lang.md approach now.

An example of a Hugo multi-lingual site: https://github.com/scholarsportal/historical-topos/tree/master/content

[zoosky]

See also https://nanoc.ws/doc/guides/creating-multilingual-sites/

[batisteo]

[i18n] isn't a feature I need, I would rather have someone else doing it, once there is consensus on the implementation
@Keats on vincent.is

So, 1 we have to find a consensus, and 2 somebody has to do it.

I’ll try to work on it, but I'm an average Web (django) developer and have no clue where to begin.

Content

I would go for the Hugo and Nikola approch, which is page-name.fr.md with a fallback to the default language if the language extension is missing.

We might want to support locale names with the country like fr_CA or pt_BR.

These files are located in the content folder, next to the other files, with the matching name.

Translations

It would be nice to have gettext-like functionality.

Translated strings would be in the translations folder at the root of the project. Names like i18n or locale are ok but seem less userfriendly than the former.

About the format, I see 2 paths:

1. gettext which is standard, but doesn’t have a first class support in Rust (inactive or experimental gettext, gettext-rs and crowbook-intl)
2. TOML-based which could be userfriendly, but NIH.

In both case, we would need an implementation of {% trans "" %} in Tera.

[Keats]

Thanks a lot for that!

I think the first step is to define exactly how everything will work, like the Rust RFCs so a bit more detailed than your post. A few points:

• sections (index.md) can have content too
• how to handle internal links and the get_url/get_page global fn (default to the current language being rendered unless it is a direct link like ./mypage.fr.md I guess?)
• how to generate the url for a language: base_url/lang/ except for the default one that stays base_url?

For i18n, I'm wondering whether having it config.toml in a languages map would work so as TOML. As you mention, I don't think there's any good i18n library right now and I expect the number of translations to be relatively small as it will be just UI. This is basically what Hugo does in your link: https://gohugo.io/content-management/multilingual/#configure-languages and https://github.com/scholarsportal/historical-topos/blob/master/config.toml for a real example. Note that Hugo also has a i18n folder with yaml in it which makes me a bit confused as to why there 2 places to define translations

We can add global function in Gutenberg without having to touch Tera so we could have {% trans(key="", lang=lang) %}. This means adding the current language to the context of every page as well.

Regarding the implementation, it shouldn't be too hard and I can help you navigate the code when you get started.

Something I'd really like to see is some big static sites with i18n (could be jekyll, hugo, pelican, anything) to see how they manage it and if they have to do some hacks to do what they want, which would highlight some missing features.

[Keats]

See #111 for the RFC

[Keats]

Closing in favour of the RFC