Sync field between two documents with shared image array

Yes, you can sync a field between translated documents! Since you're using document-level internationalization where each language is a separate document, you'll need custom logic to keep that shared image array synchronized.

The Modern Approach: Sanity Functions

Sanity Functions are the recommended solution for this type of automation. They're serverless functions that run on Sanity's infrastructure and can automatically respond to document changes. When someone updates the image array in one language version, a Function can detect that change and update all related translations.

Important note: Blueprints and Functions are currently experimental features, and the APIs are subject to change.

Why Functions Are Ideal for This

Functions provide several advantages for field syncing:

• No external infrastructure needed
• Native integration with your Sanity project
• Automatic scaling
• Direct access to document events
• Built-in Sanity client access

Getting Started

According to the official documentation, you'll need:

• Sanity CLI v3.92.0 or higher (v4.5.0+ recommended)
• Node.js v22.x for Functions
• Write access to your organization and project settings

Initialize Blueprints in your project, add a function, configure it to respond to document events on your translated documents, and deploy it. The function can query for all related translations using the __i18n_base metadata field that the document internationalization plugin adds to link translations together.

Configuration Approach

In your blueprint configuration, you can set up a document function that:

1. Triggers on create or update events
2. Filters for your specific document type with translations (_type == "yourDocType" && defined(__i18n_base))
3. Includes a GROQ projection to get the data you need

The function handler can then query for all sibling translations and patch them with the updated images array.

Important Considerations

Avoid infinite loops: Be careful that your function doesn't trigger itself. Since Functions don't currently prevent recursive loops, you'll need to design your logic carefully - perhaps by checking if the images field actually changed before patching other documents.

Timing: There will be a slight delay (usually seconds) between the original edit and when the sync completes across all translations.

Testing: You can test functions locally before deploying them to production using the CLI testing commands.

Alternative Approaches

Custom Input Component

If you need immediate, real-time syncing visible in the Studio UI, you could create a custom input component that updates all translations as the editor makes changes. This is more complex to implement but provides instant visual feedback.

Webhooks

If you prefer to host your own sync logic or need to integrate with external systems, GROQ-powered webhooks are another option. However, Functions are generally simpler for this use case since they don't require external hosting and come with built-in Sanity client access.

Shared Reference Pattern

Another architectural approach is to extract the shared images into a separate document that all language versions reference. Instead of duplicating the images array, each translation would have a reference field pointing to a single shared image collection document. This eliminates the need for syncing entirely, though it changes your content model.

Recommendation

For your use case of keeping an images array synchronized across document-level translations, Sanity Functions are the most appropriate solution. They're specifically designed for this type of content automation where you need to react to changes and keep related documents in sync, and they handle the infrastructure complexity for you.