Rendered <Content/> from collections is not translating (astro-i18n)

[narduin]

What version of astro are you using?

2.5.0

Are you using an SSR adapter? If so, which one?

none

What package manager are you using?

pnpm

What operating system are you using?

Mac

What browser are you using?

any

Describe the Bug

Hello!

I've been using astro-i18n to handle translations on my website.

Until astro@2.4.3 I was able to translate everything properly. From markdown imports to content collections.
However, since astro@2.4.4, something changed that led to the <Content /> not displaying properly. The frontmatter is ok, the post.data.body is ok but the rendered markdown is not updating on the actual page.

I opened an issue on the astro-i18n repo and despite some changes from the developer @Alexandre-Fernandez, it's still not working as before 2.4.4.

We think it might be coming from astro rather than astro-i18n.
It's possible to use const content = await Astro.__renderMarkdown(article.body) as a workaround.

Thanks a lot for any explanation :)

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-8n8f61?file=src/pages/index.astro

Participation

• I am willing to submit a pull request for this issue.

[Alexandre-Fernandez]

To clarify, we're getting the correct content object back ({id, slug, body, ...}) but when using its render function it doesn't return the headings and the <Content/> component that match its body but ones that match another content object's body instead.
I've implemented a replacement function that relies on __renderMarkdown until this is fixed.

[bholmesdev]

Hey @Alexandre-Fernandez! It looks like this is due to a slug collision in your app, where you've mapped slug to test for both internationalized entries. We currently don't allow slugs to be the same across entries:

src/content/articles/en/test.md

---
title: English article
lang: en
slug: test
---

src/content/articles/fr/test.md

---
title: English article
lang: en
slug: test # collision! May cause Content to map to the wrong entry
---

We switched to using slugs for lookups in our getCollection() helper since getEntry() relies on slugs as well. I admit we should have clear warnings whenever the same slug is used by multiple entries.

To fix this, you'll need to remove the slug property from your frontmatter and chop off the languages during route generation instead. I understand this may be frustrating, and I'll be taking a look at our slug and routing story in the next major version.

[Alexandre-Fernandez]

To fix this, you'll need to remove the slug property from your frontmatter and chop off the languages during route generation instead. I understand this may be frustrating, and I'll be taking a look at our slug and routing story in the next major version.

Thanks for your reply, what do you mean by chopping off the languages during the route generation ?

EDIT: By the way, making slugs unique doesn't really make a lot of sense because when dealing with internationalization some translated slugs may be the same, some languages have a lot of similarities (for example spanish/italian/portuguese).
Maybe you can add a frontmatter id property that takes priority over slug when present ?

[bholmesdev]

Understandable @Alexandre-Fernandez! I agree permalinks-as-identifiers is tough, since duplicate slugs are possible. We really want to reshape slug resolution in the next version of Astro, so I wouldn't want to explore patches like an id property just yet.

As for "chopping off the languages," I meant manipulating the auto-generated slug where getStaticPaths() is called, if you're using static site generation. For example:

export async function getStaticPaths() {
  const pages = await getCollection('pages');
  return pages.map(p => ({
    params: {
      slug: p.slug.slice(p.slug.indexOf('/')), // remove /[locale]/ from start of slug
    },
    props: p,
  })
}

You can also use your own identifier that avoids colliding with our own, like permalink instead of slug, and filtering on this instead.

[bholmesdev]

Closing for now, but I'll track this issue for future roadmap discussion. See withastro/roadmap#516

[Alexandre-Fernandez]

Any news on this issue @bholmesdev ?

[bholmesdev]

@Alexandre-Fernandez No updates as of now! We're planning to rework content collections in the coming months, but sadly don't have a roadmap yet. I'll update that GH discussion once we're ready to tackle it.