Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
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.
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!
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
One issue is the
Any obvious issues with the idea above, other than the
As mentioned by @SShrike, Lektor has two ways of dealing translations:
I don’t know why Armin used these names, but I like the solution with a suffix (prefix is fine too).
The non-obvious part of i18n is also the default language and URLs. Should
Thanks @batisteo !
An example of a Hugo multi-lingual site: https://github.com/scholarsportal/historical-topos/tree/master/content
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.
We might want to support locale names with the country like
These files are located in the
It would be nice to have
Translated strings would be in the
About the format, I see 2 paths:
In both case, we would need an implementation of
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:
For i18n, I'm wondering whether having it
We can add global function in Gutenberg without having to touch Tera so we could have
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.