-
Notifications
You must be signed in to change notification settings - Fork 933
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translations #13
Comments
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. |
Something that would be needed when i18n is added is a |
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. |
From mdBook: https://github.com/azerupi/mdBook/issues/5 |
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 |
(this is on hold until there is more feedback from people actually using/wanting i18n) |
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). 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 |
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. ContentI would go for the Hugo and Nikola approch, which is We might want to support locale names with the country like These files are located in the TranslationsIt 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. |
See #111 for the RFC |
Closing in favour of the RFC |
See how other tools like Hugo handle it.
The text was updated successfully, but these errors were encountered: