🔮 Sanity Create is here. Writing is reinvented. Try now, no developer setup

Understanding the use of the _translations query in internationalisation plugin readme

4 replies
Last updated: Jul 6, 2023
I do see this query inside the document internationalisation plugin readme, but I don’t get the _translations query. Why should I use that, if I already get all translations when adding language == $language

// All `lesson` documents of a single language
*[_type == "lesson" && language == $language]{
  // Get the translations metadata
  // And resolve the `value` reference field in each array item
  "_translations": *[_type == "translation.metadata" && references(^._id)].translations[].value->{

Jun 18, 2023, 5:12 PM
The language param is getting you a single translation. The
projection is getting all other translations’ title, slug, and language.
Jun 22, 2023, 4:24 PM
That is not how I see it is working. Whenever I use
*[_type == "lesson" && language == $language]
it will returns me the fully translated document since it created a separate document for each language. This is how the plugin works right now. So this is where my confusion comes from.
Jun 23, 2023, 1:35 PM
user M
Could you clarify this? Sorry for pinging you.

All is working btw, but the docs seems a bit strange to me.
Jun 28, 2023, 10:42 AM
I am struggling with this as well.
Still about to figure out how correctly call the correct translation for a dataset that has a separate language-field (like lesson) rather than a 'staged approach' via the document-internationalization-array plugin (e.g. 'course'). How to practically pass through the $language param into the groq query to only show the lessons in a specific language instead of obtaining runtime errors due to $language.
Jul 6, 2023, 11:09 AM

Sanity– build remarkable experiences at scale

Sanity is a modern headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Was this answer helpful?