sanity-plugin-internationalized-array

sanity-plugin-internationalized-array

A helper function that renders a custom input component for writing localised fields of content into an array.

This an early proof-of-concept and should not yet be used without thorough testing.

Installation

sanity install internationalized-array

Add an array to your schema by importing the helper function.

import { internationalizedArray } from "sanity-plugin-internationalized-array";

// ./src/schema/person.js
export default {
  name: "person",
  title: "Person",
  type: "document",
  fields: [
    // ...all your other fields
    internationalizedArray({
      // Required, the `name` of the outer array
      name: "greeting",
      // Required, the `type` of the inner field
      // One of: string | text | number | boolean
      type: "string",
      // Required, must be an array of objects
      languages: [
        { id: "en", title: "English" },
        { id: "fr", title: "French" },
      ],
      // Optional: just for debugging
      showNativeInput: false,
    }),
  ],
};

This will create an Array field where string fields can be added with the name title. The custom input contains buttons which will add new array items with the language as the _key value. Data returned from this array will look like this:

"greeting": [
  { "_key": "en", "value": "hello" },
  { "_key": "fr", "value": "bonjour" },
]

Using GROQ filters you can query for a specific language key like so:

*[_type == "person"] {
  "greeting": greeting[_key == "en"][0].value
}

Migrate from objects to arrays

See the migration script inside ./migrations/transformObjectToArray.js of this Repo.

Follow the instructions inside the script and set the _type and field name you wish to target.

Please take a backup first!

Why store localised field data like this?

The most popular way to store field-level translated content is in an object using the method prescribed in @sanity/language-filter. This works well and creates tidy object structures, but also create a unique field path for every unique field name, multiplied by the number of languages in your dataset.

For most people, this won't become an issue. On a very large dataset with a lot of languages, the Attribute Limit can become a concern. This plugin's arrays will use less attributes than an object once you have more than three languages.

The same content as above, plus a third language, structed as an object of string fields looks like this:

"greeting" {
  "en": "hello",
  "fr": "bonjour",
  "es": "hola"
}

Which creates four unique query paths, one for the object and one for each language.

greeting
greeting.en
greeting.fr
greeting.es

Every language you add to every object that uses this structure will add to the number of unique query paths.

The array created by this plugin creates four query paths by default, but is not effected by the number of languages:

greeting
greeting[]
greeting[]._key
greeting[].value

By using this plugin you can safely extend the number of languages without adding any additional query paths.

License

MIT © Simeon Griggs See LICENSE