@sanity/document-internationalization
Advanced tools
Create unique translations of a document based on its language, joined by a shared reference document.
This is the all-new, Sanity Studio v3 exclusive version of @sanity/document-internationalization released as v2.0.0
A complete rewrite of the original Document Internationalization plugin, exclusively for Sanity Studio v3. Major benefits from the previous versions include:
If this is your first time installing Document Internationalization, skip to the Install section.
I'm on Sanity Studio v3 and upgrading from plugin v1
I'm on Sanity Studio v3 but will stay with the older plugin for now
v1.0.0 and aboveI'm on Sanity Studio v2
v0.0.0 and abovenpm install --save @sanity/document-internationalization@studio-v3-plugin-v2
or
yarn add @sanity/document-internationalization@studio-v3-plugin-v2
Add it as a plugin in sanity.config.ts (or .js):
The only required configuration is the supportedLanguages array and the schemaTypes array.
// sanity.config.ts
import {createConfig} from 'sanity'
import {documentInternationalization} from '@sanity/document-internationalization'
export const createConfig({
// ... all other config
plugins: [
// ... all other plugins
documentInternationalization({
supportedLanguages: [
{id: 'es', title: 'Spanish'},
{id: 'en', title: 'English'}
],
schemaTypes: ['lesson'],
})
]
})
The plugin also supports asynchronously retrieving languages from the dataset, modifying the language field, adding a bulk publishing feature and adding additional fields to the metadata document.
// sanity.config.ts
import {createConfig} from 'sanity'
import {documentInternationalization} from '@sanity/document-internationalization'
export const createConfig({
// ... all other config
plugins: [
// ... all other plugins
documentInternationalization({
// Required
// Either: an array of supported languages...
supportedLanguages: [
{id: 'nb', title: 'Norwegian (Bokmål)'},
{id: 'nn', title: 'Norwegian (Nynorsk)'},
{id: 'en', title: 'English'}
],
// ...or a function that takes the client and returns a promise of an array of supported languages
// MUST return an "id" and "title" as strings
// supportedLanguages: (client) => client.fetch(`*[_type == "language"]{id, title}`),
// Required
// Translations UI will only appear on these schema types
schemaTypes: ['lesson'],
// Optional
// Customizes the name of the language field
languageField: `language` // defauts to "language"
// Optional
// Adds UI for publishing all translations at once. Requires access to the Scheduling API
// https://www.sanity.io/docs/scheduling-api
bulkPublish: true // defaults to false
// Optional
// Adds additional fields to the metadata document
metadataFields: [
defineField({ name: 'slug', type: 'slug' })
],
})
]
})
The schema types that use document internationalization must also have a string field type with the same name configured in the languageField setting. Unless you want content creators to be able to change the language of a document, you may hide this field since the plugin will handle writing patches to it.
// ./schema/lesson.ts
// ...all other settings
defineField({
// should match 'languageField' plugin configuration setting, if customized
name: 'language',
type: 'string',
readOnly: true,
hidden: true,
})
To query a single document and all its translations, we use the references() function in GROQ.
// All `lesson` documents of a single language
*[_type == "lesson" && language == $language]{
// Just these fields
title,
slug,
language,
// Get the translations metadata
// And resolve the `value` field in each array item
"_translations": *[_type == "translation.metadata" && references(^._id)].translations[].value->{
title,
slug,
language
},
}
Fortunately, the Sanity GraphQL API contains a similar filter for document references.
# In this example we retrieve a lesson by its `slug.current` field value
query GetLesson($language: String!, $slug: String!) {
allLesson(
limit: 1
where: {language: {eq: $language}, slug: {current: {eq: $slug}}}
) {
_id
title
language
slug {
current
}
}
}
# And then can run this query to find translation metadata documents that use its ID
query GetTranslations($id: ID!) {
allTranslationMetadata(where: {_: {references: $id}}) {
translations {
_key
value {
title
slug {
current
}
}
}
}
}
Often your translated documents will share the same slug. You might wish to move this into the metadata document itself using the metadataFields option in the plugin. Alternatively, you can customize the isUnique function on a slug type field.
// Add the isUnique option to your slug field
defineField({
name: 'slug',
type: 'slug',
options: {
isUnique: isUniqueOtherThanLanguage
},
}),
// Create the function
// This checks that there are no other documents
// With this published or draft _id
// Or this schema type
// With the same slug and language
export async function isUniqueOtherThanLanguage(slug: string, context: SlugValidationContext) {
const {document, getClient} = context
if (!document?.language) {
return true
}
const client = getClient({apiVersion: '2023-04-24'})
const id = document._id.replace(/^drafts\./, '')
const params = {
draft: `drafts.${id}`,
published: id,
language: document.language,
slug,
}
const query = `!defined(*[
!(_id in [$draft, $published]) &&
slug.current == $slug &&
language == $language
][0]._id)`
const result = await client.fetch(query, params)
return result
}
In previous versions of this plugin, translations were stored as an array of references on the actual documents. This required a base language, lead to messy transaction histories and made deleting documents difficult.
In this version of the plugin, translations of a document are stored as an array of references in a separate document of the type translation.metadata, and one is created for every document that has translations. A document with no translations will not have a metadata document.
This means if you have 100 documents and they are all translated into 3 languages, you will have 400 documents. Keep this in mind for extremely high-volume datasets.
There are two scripts in the ./migrations folder of this repository. They contain scripts that should help move your content over – however, they may require updating to match your current settings.
These have not been thoroughly tested on all platforms. Please take a backup before proceeding. Test on a duplicate dataset.
./migrations/renameField.ts will update the language field on translated documents./migrations/createMetadata.ts will create metadata documents for the arrays of references and unset those fields from translated documentsMIT © Sanity.io
This plugin uses @sanity/plugin-kit with default configuration for build & watch scripts.
See Testing a plugin in Sanity Studio on how to run this plugin with hot reload in the studio.
Run "CI & Release" workflow. Make sure to select the main branch and check "Release new version".
Semantic release will only release on configured branches, so it is safe to run the release on any branch.
FAQs
Create unique translations of a document based on its language, joined by a shared reference document.
The npm package @sanity/document-internationalization receives a total of 12,347 weekly downloads. As such, @sanity/document-internationalization popularity was classified as popular.
We found that @sanity/document-internationalization demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 56 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
License exceptions modify the terms of open source licenses, impacting how software can be used, modified, and distributed. Developers should be aware of the legal implications of these exceptions.
Security News
A developer is accusing Tencent of violating the GPL by modifying a Python utility and changing its license to BSD, highlighting the importance of copyleft compliance.
Security News
In an open letter, JavaScript community leaders urge Oracle to give up the JavaScript trademark, arguing that it has been effectively abandoned through nonuse.