Get help on Discord

Publishing non-base language documents with document-internationalization plugin

9 replies
Last updated: Mar 3, 2023
Hi, I'm using the document-internationalization plugin which out of the box works great!
I've been looking through the channel for answers on a question of mine but couldn't find an answer, although I guess it's been discussed before:

One need from clients of our's is to be able to publish content in one language only,
which is not the base language.
If I add a new page, and wants to select
English instead of Swedish (base), the dropdown is broken and I'm unavailable to add a page only in English.
Is there any solution to this?

My config looks like this:

documentI18n({
  languages: i18n.languages,
  "idStructure": "delimiter",
  "referenceBehavior": "weak",
  "withTranslationsMaintenance": false,
    "fieldNames": {
      "lang": "__i18n_lang",
      "references": "__i18n_refs",
      "baseReference": "__i18n_base"
  },
  customFlagComponents: {
    'sv': () => '🇸🇪',
    'en': () => '🇬🇧',
  }
}),
AI Update

I understand this is a frustrating issue! Based on the official documentation and GitHub repository, I need to clarify what's happening and provide you with practical solutions.

The behavior you're experiencing where the dropdown appears "broken" when trying to create a document in a non-base language (English instead of Swedish) appears to be a workflow limitation of how the plugin is designed, though the exact cause isn't fully documented.

How the plugin works

The @sanity/document-internationalization plugin creates unique translations of documents that are joined together by a shared translation.metadata document. This metadata document maintains references to all language versions of a document.

The plugin's typical workflow expects you to:

  1. Create a document in one language first
  2. Then use the language selector to create translations from that initial document

This is because the translation.metadata document needs at least one document to reference before it can establish the translation relationship structure.

Practical solutions

Option 1: Create Swedish first, then immediately translate (Most reliable)

Create the document in Swedish (your base language), save it, then immediately use the language dropdown to create the English version. You can then:

  • Leave the Swedish version unpublished if you only want English content visible to end users
  • Keep minimal placeholder content in Swedish while focusing work on the English version

This respects the plugin's architecture while achieving your goal of having English-only content published.

Option 2: Enable allowCreateMetaDoc configuration

The plugin has an allowCreateMetaDoc option that was designed for tying together pre-existing documents. Try adding this to your configuration:

documentI18n({
  languages: i18n.languages,
  "idStructure": "delimiter",
  "referenceBehavior": "weak",
  "withTranslationsMaintenance": false,
  "allowCreateMetaDoc": true, // Add this
  "fieldNames": {
    "lang": "__i18n_lang",
    "references": "__i18n_refs",
    "baseReference": "__i18n_base"
  },
  customFlagComponents: {
    'sv': () => '🇸🇪',
    'en': () => '🇬🇧',
  }
})

This enables the "manage translations" button without requiring a translated version to exist first, which might help with your workflow.

Option 3: Report this as a usability issue

Since this specific workflow limitation affects your clients' needs, it may be worth checking the plugin's GitHub issues to see if others have reported similar needs, or opening a new issue describing your use case. The dropdown behavior when trying to select a non-base language on document creation could be improved, and the maintainers may have additional workarounds or could consider this for future improvements.

What to try first

I'd recommend trying Option 2 (allowCreateMetaDoc: true) combined with Option 1 (creating Swedish first, then English). Your configuration otherwise looks correct, so this isn't a configuration error—it's about working with the plugin's current workflow design.

If the dropdown is truly "broken" (showing errors or completely non-functional rather than just not allowing the selection), that would be worth reporting as a bug on the GitHub repository with screenshots or console errors.

Show original thread
9 replies
This is one of the main challenges that the next version of the plug-in addresses. It’s available in beta at the moment if you’d like to try it out.
It offers a very different way of storing the translated references. So you would need to make some schema changes. Take a look at the readme:


https://github.com/sanity-io/document-internationalization/tree/studio-v3-plugin-v2
Magical! Thanks
user T
, will try that out for sure 👌 🎉
Tried out the new version during the afternoon, it worked really well and it enables us to do exactly what we want! Amazing job, feels like this version will improve the experience for both editors and developers👏 👏 👏
Thanks Henrik!
If you have any other feedback while using it please let me know 🙂
Yes, will do! Will use it more in depth in the coming days so I’ll shout if I bump into something 😀
One thing I was thinking of
user T
that there might already be a solution for:
We would like to add something like a "completion rate" for our editors in the list previews, for example
• Page exists in Swedish and English, but not Norwegian, and display that in the list subtitle (if we for example wants to filter out and show only one language in the lists)
• In the V3 version we had access to the current language-refs and could accomplish that by checking that field
Is there a way to do something similar in the coming version?

The groq query for getting languages worked perfect:

"_translations": *[_type == "translation.metadata" && references(^._id)].translations[].value->{
  title,
  slug,
  language
}
Is it/would it possible to fetch those values inside a 
page.tsx
schema document for example?
The only way to do an async call that shows in document list views is to put a custom component inside the ‘media’ key. So you’d need to create a sort of custom icon which would indicate that all translations have been completed.
Thanks, will try that 🙂

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?