gt-sanity@2.1.0

Vue d’ensemble

gt-sanity v2.1 ajoute la localisation au niveau des champs : au lieu de créer un document distinct par paramètre régional, vous pouvez désormais stocker la valeur de chaque langue dans un même document à l’aide de tableaux internationalisés. Le plugin génère les types de schéma pour vous, inclut une interface d’édition intégrée par paramètre régional et fait passer la traduction par le même workflow GT que vous utilisez déjà — les valeurs traduites sont fusionnées directement dans le document source.

La structure des données correspond à celle de sanity-plugin-internationalized-array ([{ _key, _type, language, value }]), donc le contenu existant utilisant internationalized-array fonctionne sans aucune migration.

Nouveautés

Localisation au niveau des champs (tableau internationalisé)

La traduction au niveau du document reste le modèle par défaut : chaque paramètre régional a son propre document, lié via @sanity/document-internationalization. Ce modèle convient aux documents dont l’ensemble du contenu varie selon la langue.

Le nouveau modèle au niveau des champs conserve un document unique et localise directement chaque champ :

{
  _id: 'post-123',
  _type: 'post',
  title: [
    { _key: 'x1', _type: 'internationalizedArrayStringValue', language: 'en', value: 'Hello' },
    { _key: 'x2', _type: 'internationalizedArrayStringValue', language: 'es', value: 'Hola' },
  ],
}

Activez-la avec la nouvelle option internationalizedArray (ou son alias descriptif, fieldLevelLocalization) :

import { defineConfig } from 'sanity';
import { gtPlugin } from 'gt-sanity';

export default defineConfig({
  plugins: [
    gtPlugin({
      sourceLocale: 'en',
      locales: ['es', 'fr', 'ja'],
      translateDocuments: [{ type: 'post' }],
      internationalizedArray: { enabled: true },
      translationLevel: 'internationalizedArray',
    }),
  ],
});

Types de schéma générés

Lorsqu’il est activé, le plugin génère des types de schéma internationalizedArray* (par ex. internationalizedArrayString, internationalizedArrayText) à partir des mêmes sourceLocale / locales que vous transmettez déjà à gtPlugin — les paramètres régionaux ne sont définis qu’une seule fois. Utilisez-les dans vos schémas comme n’importe quel autre type :

defineField({
  name: 'title',
  type: 'internationalizedArrayString',
});

fieldTypes détermine les types générés. Par défaut, sa valeur est ['string', 'text'] ; il accepte 'block' pour Portable Text, ainsi que des définitions d’objet personnalisées pour des structures de valeur arbitraires :

internationalizedArray: {
  enabled: true,
  fieldTypes: [
    'string',
    'text',
    'block',
    { name: 'seo', type: 'seoFields' }, // génère internationalizedArraySeo
  ],
},

Vous pouvez également personnaliser les noms de types générés avec typePrefix (les alias de compatibilité sous les noms standard internationalizedArray* sont conservés par défaut), ainsi que les libellés de paramètres régionaux affichés dans le Studio avec languageTitles ou getLanguageTitle.

UI d’édition inline par paramètre régional

Les types générés incluent un champ Studio conçu à cet effet : chaque langue s’affiche sous la forme d’un éditeur inline libellé (sans lignes d’objet repliées ni boîtes de dialogue d’édition), avec des boutons d’ajout et de suppression pour chaque paramètre régional. La langue source ne peut pas être supprimée.

Si vous préférez utiliser votre propre UI, l’option components vous permet de remplacer les slots input, item et field — ou de passer false pour revenir au rendu par défaut de Sanity. La traduction n’est affectée dans aucun des cas, puisqu’elle fonctionne à partir des données stockées plutôt que des composants.

`translationLevel` et mode mixte

La génération du schéma et le routage des traductions sont indépendants : activer internationalizedArray ajoute uniquement des types de champ modifiables. La nouvelle option translationLevel détermine comment les documents correspondants sont traduits :

'document' (par défaut) — traduction de l’ensemble du document avec un document par paramètre régional, comme en v2.0.
'internationalizedArray' — tous les documents correspondants sont localisés directement sur place via des tableaux internationalisés.
'mixed' — les types de document listés dans fieldLevelDocuments utilisent la stratégie par tableau ; tout le reste reste au niveau du document.

gtPlugin({
  sourceLocale: 'en',
  locales: ['es', 'fr'],
  translateDocuments: [{ type: 'post' }, { type: 'siteSettings' }],
  internationalizedArray: { enabled: true },
  translationLevel: 'mixed',
  fieldLevelDocuments: [{ type: 'siteSettings' }], // localisé directement dans le document
});

Les types de document localisés sur place sont automatiquement exclus de @sanity/document-internationalization, et ne reçoivent donc ni badges de langue ni modèles de document propres à chaque paramètre régional.

Importation directe

Les documents au niveau des champs suivent le même workflow GT que vous utilisez déjà. À l’importation, les valeurs traduites sont réinjectées dans le même document : seul le paramètre régional cible est mis à jour, et toutes les autres langues — y compris les modifications apportées pendant l’exécution de la traduction — restent intactes.

Les états de traduction dans le Studio restent désormais exacts après les importations directes et l’actualisation de la page, au lieu d’indiquer les traductions terminées comme « non commencées ».