Support for localization (e.g. for Contentful)

[henniaufmrenni]

While I guess that it is currently possible to localize MDX based on frontmatter tags, doing this would mean that the filenames would need to be different, resulting in different slugs which would certainly not be ideal. I guess there are other ways to achieve it, but none of them seem ideal, that's why it would be great to support l10n (and also just because Contentlayers goal is to be the abstraction layer between data and code).

I assume that there could be several ways for structuring the MDX files, but what comes to my mind first is either via file name eg. /pages/about.mdx /pages/about.de.mdx or via subfolders eg. /pages/en/about.mdx /pages/de/about.mdx.

Edit: the following structure seems pretty nice, but would depend on #11

├── data
│   ├── pages
│   │   ├── about
│   │   │   ├── index.mdx
│   │   │   ├── index.de.mdx
│   │   │   ├── picture.jpeg
│   │   ├── privacy
│   │   │   ├── index.mdx
│   │   │   ├── index.de.mdx
│   │   │   ├── cover.jpeg

For Contentful one just needs to add &locale= https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/localization

[schickling]

Thanks for opening this issue. I agree there are way how Contentlayer could make working with localized content easier. This is something I'm planning to explore some time soon together with introducing localization support for other CMS like Contentful.

Until then when using MD(X) content I suggest to work around the issue like you've hinted at above. If you need more help with the actual implementation (e.g. a computed slug field) I'm happy to help via Discord.

[timlrx]

+1 for this. Currently, we are maintaining two separate repositories one with support for i18n based on the file name and the main one without. Would be great if content layer eases some of that pain and reduces the extra boilerplate code for i18n.

One way would be to add a locale property to allBlog. Or if contentlayer already stores the entire path field in allBlog, perhaps we could parse it ourselves.

[timlrx]

Just went through leerob.io changes, it seems like it is possible to do so via computedFields, so that should make it quite simple! Is there any documentation on it? Thanks.

[schickling]

The documentation work on this is still WIP but happy to help you out in our Discord if you're running into problems with it. For now, I'd encourage you to copy & paste from the examples (e.g. Lee's blog) and experiment from there.

[willin]

allBlog filter perhaps it's not a good way to it...

[henniaufmrenni]

In the end I solved this for my project by using the subfolder-based structure suggested above and getting the slug and language from frontmatter, but if one would set up the correct regex I assume it should also work with computed fields as suggested above.

@schickling I think it's safe to close this, as this doesn't seem like an issue, but rather a matter of documentation?

[schickling]

Thanks a lot for the update @henniaufmrenni. I'll keep this issue open since some CMS (e.g. Contentful) have a first-class localization feature that's currently not yet supported by Contentlayer but should be.

I also agree that we should better document how to implement localization/internationalization scenarios when using the source-files plugin. (cc @seancdavis)

[rsipakov]

Just went through leerob.io changes, it seems like it is possible to do so via computedFields, so that should make it quite simple! Is there any documentation on it? Thanks.

@timlrx Could you provide more explanation about this way? Thank you!

[timlrx]

@rsipakov, here's a psuedocode assuming 'en' as the default:

const getLocale = (path) => {
  const pathArray = path.split('.')
  return pathArray.length > 2 ? pathArray.slice(-2)[0] : 'en'
}

// In contentlayer.config.js
export const Post = defineDocumentType(() => ({
  name: 'Post',
  fields: {
   . . .
  },
  computedFields: {
    locale: {
      type: 'string',
      resolve: (doc) => {
        return getLocale(doc._raw.sourceFilePath)
      },
    },
  },
}))

This would generate a new locale field for each post which you can use in your pages/routing.

[rsipakov]

timlrx

Hi @timlrx! Thank you for the quick response. I mentioned your comment in the solution by @willin. Can you comment on that?

[u-till]

has anything happened here in the meantime? i cannot seem to find anything in the documentation. Does someone know of a repository where i could go peek how the internationalisation was done? I am in the process of building a blog based on the Next.js Contentlayer Blog Starter and haven't found any good ressource on how to implement i18n.

Would be really happy if anyone has an example or anything.