Structure Builder breaking sanity-plugin-intl-input translate features

13 replies
Last updated: Jan 28, 2026
I am using sanity-plugin-intl-input and I need to use structure builder to organize my documents to be more user friendly. My issue is that whenever I attempt to follow the structure builder documentation , the translate features in the studio no longer show. The sanity-plugin-intl-input structure instructions do not seem to line up with any examples I can find. How can I add basic structure builder features to organize documents translated with sanity-plugin-intl-input ?
If transitioning to the new
document-internationalization will help, I can do that, but I did not see anything in there that addresses my specific issue.
AI Update

The key issue you're encountering is that when you customize the Structure Builder, you need to work with the getFilteredDocumentTypeListItems() function rather than replacing it entirely. This function is what makes the internationalization plugin recognize translated documents as a single entity.

Based on a community answer from the Sanity team, here's how to organize your translated documents with custom structure:

The Solution

The trick is to get the filtered items first, then manipulate that array to organize them into groups. Here's a working example:

import S from '@sanity/desk-tool/structure-builder'
import * as Structure from '@sanity/document-internationalization/lib/structure'

export default () => {
  // Get the filtered document type list items from document-internationalization
  const items = Structure.getFilteredDocumentTypeListItems()

  // Group the items into different categories
  const groupedItems = items.reduce(
    (reduced, item) => {
      // Check whether the item should be included in your custom group
      if (item.id === 'page' || item.id === 'post') {
        return {
          ...reduced,
          mainPages: [...reduced.mainPages, item],
        }
      }

      // Otherwise, add it to the general group
      return {
        ...reduced,
        other: [...reduced.other, item],
      }
    },
    {
      mainPages: [],
      other: [],
    }
  )

  return S.list()
    .id('root')
    .title('Content')
    .items([
      // Create a nested list for your main pages
      S.listItem()
        .title('Website Pages')
        .child(
          S.list()
            .id('mainPages')
            .title('Website Pages')
            .items(groupedItems.mainPages)
        ),
      S.divider(),
      // Include the rest of the documents
      ...groupedItems.other,
    ])
}

How It Works

  1. getFilteredDocumentTypeListItems() returns an array of list items that already have the translation logic baked in
  2. You can then use JavaScript array methods like reduce(), filter(), or map() to reorganize these items
  3. The key is checking item.id to identify which document types should go where
  4. You can create nested lists using S.listItem().child(S.list().items([...]))

Studio v3 Update

If you're using Studio v3, the import paths have changed slightly:

import {structureTool} from 'sanity/structure'
import * as Structure from '@sanity/document-internationalization/lib/structure'

export const structure = (S) => {
  const items = Structure.getFilteredDocumentTypeListItems()
  // ... same logic as above
}

// In sanity.config.ts
export default defineConfig({
  plugins: [
    structureTool({structure}),
    documentInternationalization({
      // your i18n config
    })
  ]
})

Should You Migrate to document-internationalization?

Yes, migrating to @sanity/document-internationalization is recommended because:

  • It's actively maintained by Sanity
  • It has better documentation and community support
  • The structure customization pattern is the same as what you're trying to achieve
  • It works well with Studio v3's Structure Tool

The migration shouldn't be too difficult since both plugins use similar concepts, and the structure customization approach described above works with both.

Show original thread
13 replies

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.

Was this answer helpful?