I’ve been maintaining my open-source flat-file CMS Typemill for more than eight years. During all that time, one feature request never changed: When will Typemill support multilingual websites?
The reason it took so long is simple: multilingual support is one of the hardest features to implement in a flat-file CMS. That’s also why only a handful of flat-file CMSs really support multilingual websites today, such as Kirby, Statamic, Grav, or Automad.
Different architectures, different trade-offs
Flat-file CMSs solve multilingual websites in very different ways. Some systems, like Grav, store language variants directly inside the same page folder. This makes switching languages straightforward and keeps pages naturally connected.
Typemill, however, follows a different approach. It builds a full index of all pages to manage navigation, deeply nested content structures, and drag-and-drop ordering. This makes content structuring very flexible — but it also means that different languages cannot simply live side by side in the same folder.
Projects instead of folders
The solution I ended up with was introducing projects. Each project has:
- Its own content space
- Its own navigation
- Its own logic and index
Projects were not originally designed for multilingual websites — they were an unplanned first step. It quickly turned out that they are useful in general. Since Typemill can also publish websites as PDF books or EPUB files, projects can also be used to manage multiple publications within a single installation.
For multilingual websites, projects turned out to be a natural fit. Each language becomes its own project — isolated, clean, and independently manageable — while still being part of the same system. All that’s needed is a global index that keeps track of how language variants are linked to each other.
The missing piece: AI translation
Even with a solid structure, one major problem remained: translation workflow.
Copying pages, translating articles, and updating metadata manually works for small websites. But it consumes a lot of time and quickly breaks down as a project grows.
One big advantage of flat-file CMSs compared to database-driven systems is their use of simple Markdown files. Markdown is also the native output format for nearly all LLM services and APIs. This makes integrating AI services into flat-file CMSs surprisingly straightforward. Using this advantage to automate translations is, frankly, a no-brainer.
Typemill already integrated AI services through a separate interface called Kixote. To fully automate translations, you simply activate a checkbox. When you create a new language page, Typemill copies the original content into the target language project and performs one additional step: it sends the content to an AI service and stores the translated response.
That’s it.
Currently, auto-translation only runs when a translation page is created. If the original content changes later, translations still need to be updated manually. But that’s a comparatively small next step.
Final thoughts
Multilingual support in flat-file CMSs has always been a hard problem — structurally, conceptually, and operationally. AI doesn’t solve every issue, but it removes the biggest pain point: repetitive manual work. In my view, if you’re building tools for content creators today, multilingual support should at least include an option to automate translations.
Watch the walkthrough
I created a short 5-minute demo video that shows how easy it is to set up a multilingual website with Typemill using this approach:
If you’re curious to learn more, visit the Typemill website:
https://typemill.net
Top comments (1)
Any user-facing software that I work on and are in control of supports i18n. Even for just one language I would use placeholders and a text file with the labels. It makes many things much easier in the long run and introducing a 2nd language is really easy