Kia ora CloudCannon Community!
We’ve recently published a blog article around managing a multilingual site in CloudCannon. There are a two main approaches to going about this.
One is splitting your content into separate directories, and independently managing each like you would any other collection in CloudCannon. The other is tagging your html with data tags and pairing this with a set of data file of translations, then using the two to generate pages in other languages as part of your build.
Have a read for more details if this is something that might be of interest to you.
I’d be happy to answer any questions or hear any feedback if anyone has any!
5 Likes
I recently set up a project using Rosey (so, the second approach @Tom_Richardson mentioned above) to adapt an Australian site for a U.S. audience. While it wasn’t a traditional translation (since we’re dealing with English → English), implementing Rosey allowed us to future-proof the site for when the client expands into non-English markets.
In our case, Rosey wasn’t used to manage actual translation strings. Instead, we used it to generate a near-identical copy of the site under an en-us subfolder (and therefore on the /en-us/ subpath). Interestingly, we didn’t need to tag any content at this stage—simply adding Rosey to the project was enough to get a duplicate version of the site output under the new locale.
From there, we used JavaScript to handle localization adjustments such as:
- Switching UK → US spelling (e.g., “organise” → “organize”)
- Reordering unit preferences (e.g., displaying
ft/m instead of m/ft)
The client also wanted to restructure the navigation for their U.S. users. To do this, we tagged the nav data with data-rosey="nav" and then created a custom U.S. nav configuration in the site files. On build, JS swaps out the nav content based on locale (so the user doesn’t have to define the nav in the Rosey files).
Finally, a handful of pages needed to differ structurally or exist only in the U.S. version. While this could have justified using the per-directory approach, the vast majority of pages were shared across locales. So, instead, we allowed the client to maintain a few unique pages by creating versions directly under an /en-us/ directory. Then, during the build, JS checks for locale-specific overrides and replaces any Rosey-generated pages with the explicitly defined ones.
Overall, this hybrid setup has worked really well—Rosey handles the heavy lifting for most content, while JavaScript provides the flexibility needed for market-specific tweaks without overcomplicating the project.
Happy to answer any questions if anyone is considering a similar approach!
3 Likes
Hugo does a lot of the work for you and uses something similar to the ‘locales per directory’ approach. I translate the markdown files automatically with the Google Translate API and use a script to automate the whole duplication process.
The fact that Hugo supports multilingual websites by default makes it a very good choice for Europeans (we have many languages).