I did my research looking for a best way to manage multilingual website with Hugo.
I figured there are two options here. First option is to keep translation content in posts themselves (like “about.md”, “about.fr.md”,etc.).
Readability is really nice here. The biggest drawback is that markdown language has its limitations. If you need more complicated layouts, you start adding more html tags in your .md files, and readability vanishes. Also, if you decide to made a change in your formatting (like modifying Bootstrap grid), you need to do that changes in every of your .md file. It seems, that those changes are for Templates. But, if you are going for templates (that’s the second option), you face other issues. Second option is to keep translated strings in yaml/toml data files, and perform translation in templates and partials.
Readability of language data files seem to be worse here. Special characters, hard to read. Extra complexity with Keys for translated data, considering those translations are to be used in one single place.
Please, guide me which option would you select and why. Or, maybe there is a third option?
I find translating content and localizing strings are two very different yet parallel things. I don’t see them as “options” to doing the same thing as none can substitute the other.
Best practice for me is to translate your edited content (markdown) using file or directory system, and translate your theme or project’s strings using Hugo’s i18n built-in solution.
As you mentioned, it’s translated md files, and accessing data files based on what you need. I use both the i18n method pulling from a list of strings (one file per language) and also using index on json data. It’s kind of a mix.
For instance, I use this shortcode:
… pulling from bilingual json data:
I have a script that grabs the json files before starting hugo server.
Thank you! Great example here. I really like how clean the website is.
My project is more like your Carousels. I see you have some extensive html there. Similar to what I want to achieve.
The difference is that I have a couple of landing pages in 10 languages with responsive design requirements. If I put everything in .md files, I will have to include those DIVs (or shortcodes) in them. They will not look as clean and easy to maintain as your .md files. Later I will have to edit all those DIVs (shortcodes) in 10 places. Splitting data and view seems logical, but I do not like the idea of losing this simplicity of .md files.