Localisation support

[isaachinman]

Hey, I've had a look through the website, and also all the GitHub issues.

I see no mention of i18n or localisation.

Am I correct in assuming that pages-cms currently does not support localisation at all? That seems like an unexpected omission from a CMS.

[hunvreus]

No yet.

I had full i18n support in its precursor (Jekyll+), but haven't gotten around to adding it to Pages CMS.

Here's how you could help:

• Tell me what SSGs you use.
• Tell me how the multilingual support is done. My assumption is that:
  • Collections and files are by default for the default language.
  • Entries for different languages are in subfolders with the language code as the name (e.g. en or en-US).
  • Matching between translations are made with the filename. For example src/posts/my-first-post.md could have a Spanish version available at src/posts/es/my-first-post.md.
• Tell me which platforms you think are getting the i18n interface "right". Contentful? Sanity? CloudCannon?

I'll need l10n support too. This is probably a few weeks away from being done as I'm right now working on a few other key features (e.g. custom fields, 3rd party storage support).

[isaachinman]

Sure, happy to help.

SSGs

Kind of a weird question, what makes you ask? Your CMS implementation should be agnostic of SSG or any framework. I use CMS content across NextJs (SSG and SSR), Node API layer, and React Native.

I think that writing "Next/Nuxt/whatever plugins" is where so many SaaS go wrong. Just keep it simple!

I would expect to be able to somehow extract/consume a locale config, where the default locale and all other locale codes are available.

Multilingual Support

I have not actually used pages-cms yet, so I can't really give any advice or opinion on how to structure the data within the existing dir hierarchy.

One very important thing to keep in mind is that any reasonable i18n implementation needs fallback logic. That is, if I have a fr-BE locale which is missing some keys/translations, it should first fallback to a fr locale if one is present, and ultimately fallback to whatever my default locale is – could be en-GB.

Fallbacks do not need to be represented in the actual filesystem, but it would be good to at least export a function that handles the logic. The whole point is that we don't want duplicate content.

Good examples

Frankly, I don't have any for you. I have had to manually implement locale fallbacks with every CMS I've used, as one example. Having "full data" for every locale is a complete antipattern. Normally, a regional locale like fr-BE is only used for specific overrides for that market, and all other content can acceptably be "normal French".

Another weird and frustrating quirk is that almost all CMS providers seem to want to price heavily on i18n. I remember working at a fortune 100 org and paying Contentful >100k/year, just because we had 30+ locales.

I have been involved in i18n for quite some time now. I created next-i18next and have been working with the Vercel/Google/i18next teams for years.

For some reason, no one can seem to get i18n right, despite it being a relatively simple subject, once you get past some initial specification. The core problem, I think, is that there are a lot of possible ways to implement i18n. In other words, everyone is doing it slightly differently. That being said, there are strict ISO standards for this stuff, which I recommend you read up on.

Hilariously, I originally wrote next-i18next because there was no other option in 2017. It's now 2024 and it's still impossible to translate the NextJs 404 page.

File formats

I see you mentioning markdown. Again, I've not actually used pages-cms as i18n is one of a few critical features for me to even get started. Is markdown the only file format you support? I would strongly prefer JSON and would have to write a util to convert md to json if not.

---

I would actually be open to discussing your implementation on a call, if you want. Cheers!

[hunvreus]

Kind of a weird question, what makes you ask? Your CMS implementation should be agnostic of SSG or any framework. I use CMS content across NextJs (SSG and SSR), Node API layer, and React Native.

Pages CMS is SSG/framework agnostic.

But it's useful for me to get context as I'll need to test the translation in actual websites/apps to make sure it works as intended for the end user. I assume that I'll need to support a few different i18n strategies.

One very important thing to keep in mind is that any reasonable i18n implementation needs fallback logic. That is, if I have a fr-BE locale which is missing some keys/translations, it should first fallback to a fr locale if one is present, and ultimately fallback to whatever my default locale is – could be en-GB.

Good point. I also plan on making things configurable so that people can figure out what works best for them, including what locale codes they want to use.

Another weird and frustrating quirk is that almost all CMS providers seem to want to price heavily on i18n. I remember working at a fortune 100 org and paying Contentful >100k/year, just because we had 30+ locales.

i18n will be free on Pages CMS. I may want to offer Pro features around translation (e.g. automated translation for example) but I don't see why I would need to charge for that.

For some reason, no one can seem to get i18n right, despite it being a relatively simple subject, once you get past some initial specification. The core problem, I think, is that there are a lot of possible ways to implement i18n. In other words, everyone is doing it slightly differently. That being said, there are strict ISO standards for this stuff, which I recommend you read up on.

Indeed. I have some experience dealing with it (everything from Chinese and Burmese to Korean and Arabic) and have seen a wide range of setups.

I see you mentioning markdown. Again, I've not actually used pages-cms as i18n is one of a few critical features for me to even get started. Is markdown the only file format you support? I would strongly prefer JSON and would have to write a util to convert md to json if not.

No, it supports frontmatter, JSON, YAML, TOML, Markdown, HTML , ...

[arossmann]

For me, i18n support would also be great. I currently use Hugo, so your assumptions are fitting my case.

[L-U-C-K-Y]

This would be a great addition!

Maybe we could inspire us from docusaurus: https://docusaurus.io/docs/i18n/introduction

It does not translate the file-name (they say due little SEO value) and the file name should match.

We could specify a base language and then create a secondary structure for the translation files, as they mention:

website/i18n
└── fr
    ├── code.json  # Any text label present in the React code
    │              # Includes text labels from the themes' code
    ├── docusaurus-plugin-content-blog # translation data the blog plugin needs
    │   └── 2020-01-01-hello.md
    │
    ├── docusaurus-plugin-content-docs # translation data the docs plugin needs
    │   ├── current
    │   │   ├── doc1.md
    │   │   └── doc2.mdx
    │   └── current.json
    │
    └── docusaurus-theme-classic # translation data the classic theme needs
        ├── footer.json   # Text labels in your footer theme config
        └── navbar.json   # Text labels in your navbar theme config

[isaachinman]

It does not translate the file-name

This is a CMS and has nothing to do with your actual frontend/web routes... If you wanted to localise slugs, you should put a string entry called slug inside your CMS document.

[CarloBu]

thumbs up for this discussion. I recently found this CMS, for me Pages CMS looks like the ultimate SSG CMS option, I like the clean UI and simple user experience. I love that there are custom fields to customize CMS to my own needs. Just one missing ingredient is missing, that's i18n support. I understand that for most people in the world, i18n is not a big deal, but at least in Europe, two locales (local+en) are a common requirement when building business websites. I'm looking forward to the i18n Pages CMS, after the migration to NextJS of course.
Ronan, I hope you will not drown in the react state management swamp ;)

[hunvreus]

I'll have l10n sorted out in the next version (built on Next.js, so that should be fairly straightforward).

For i18n (i.e. multilingual contnet), I'll likely release a beta on a subdomain for those of you that want to try it out.

The question I have for now is: what SSG/frameworks should I support first? Next.js? Nuxt? Astro? Hugo?

[isaachinman]

Again I would urge you to build an agnostic CMS and not get distracted by frameworks or their implementation details.