You are using a theme so that depends what the theme index page is displaying.
If you want to experiment, skip the theme and write the templates directly in the templates/ directory (you can copy the ones from your theme if you want).
1 Like
Gotcha. Thanks.
Is it possible to do something like {% set section = get_section(path="_index.md") %} but having it use _index.md or _index.en.md automatically?
Iām assuming I need to use get_section in my index.html to serve _index.md or _index.en.md depending of the language.
Not right now.
You donāt necessarily need that. Look at the test i18n site index page: https://github.com/getzola/zola/blob/next/test_site_i18n/templates/index.html
It will be generated correctly for all languages automatically as it only uses the section variable that is passed down in all cases.
The plan is to release v0.6.0 with what is currently on the next branch this weekend. It is missing things but we will get more feedback on multilingual if it is actually released and I donāt think the fundamental structure will change.
Any big blocker/bad design to consider before that?
With i18n, is a translations file supported yet? I.e. something like Fluent where I can easily grab a translation.
Currently I can theoretically make a base template with a ton of blocks, but that sounds like a big headache to maintain and still has code duplication.
Not yet! The i18n support currently in is a first step, about translating the content.
As mentioned above, I wasnāt sure people wanted full-on i18n translations for templates so I left it out for now.
Adding fluent is definitely planned for later imo, I was just waiting for more feedback on Zola multi lingual story beforehand.
Ah I see. Iāve been working on porting over my existing site to one that has English/Korean translations, but to do so currently I have to duplicate everything, or use the mentioned method above. If an i18n translations file or files were to be supported it would be really nice.
Working on translation for my blog I wanted a way to get a localized page from a template but get_page the page corresponding to path but is not translation-aware. The easiest way iāve found is to implement a has_page function and then make a i18n_page macro.
But of course patching zola on my side is not my favorite solution so iām here to ask what do you think or recommend for get_page translations?
I think it makes sense to add a lang param to some Tera functions but probably not in the next release, I need some time to think about it.
Iām also hoping to get some more feedback from i18n users, other than the Fluent integration.
Would you take a PR for the has_page function, though? So i can use my macro directly on next 
No, as there might be a better solution and I donāt have to add a function just to remove it one version later
I just scanned through this thread. Does this mean that a site path like {config.base_url}/{language}.lproj would be acceptable as well? ā¦and still allow for non-i18n content outside of the language directories?
I was just trying to build an apple help bundle with hugo and the i18n was just too inflexible. Maybe it could be a good edge case to test the proposal.
There are no languages directories, the pages with a lang automatically gets {language}/prepended to their path, thatās it.
You can already try it with Zola 0.8 and there are improvements in the next branch already: taxonomies with the same name in multiple languages and being able to fetch the page/section of a particular language.
If you have any feedback on it, please leave some comments!
Maybe let me ask differently then 
Could those pages also have some/path/{language}.foo/ prepended instead?
No way to do that automatically no.
Since this is semi-related to i18n, could anybody reading this have a look at Non slugification of paths ?
This is a pretty huge change that will probably get its own major release.
There is a PR to improve significantly the experience: https://github.com/getzola/zola/pull/1148#issuecomment-691667324
Feedback appreciated and needed!