
Grab your gear: The official Sanity swag store
Read Grab your gear: The official Sanity swag storeThe recommendation against using Portable Text with field-level translation comes down to a technical limitation around attribute counts in Sanity's content structure.
Portable Text generates a massive number of attributes because of its complex, nested structure. Each block, mark, annotation, and inline object creates its own set of paths in the document. When you combine this with field-level localization, where each language creates its own complete set of nested paths, the attribute count multiplies rapidly and can exceed Sanity's attribute limits.
Here's the key difference:
If you implement field-level translation with Portable Text, you risk:
According to Sanity's documentation on this specific issue, this can create situations where content becomes stuck and difficult to resolve.
For content that includes Portable Text or any rich text content, use document-level localization instead. This approach creates separate documents for each language version, completely avoiding the attribute multiplication problem while still giving you full flexibility with complex content structures.
Field-level localization works fine for simple fields like strings, numbers, or basic objects—just not for Portable Text or block content.
If you're looking at plugins like the sanity-plugin-intl-input, be aware it only works with the deprecated Studio v2 and still carries the same Portable Text limitations.
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.
Content operations
Content backend


The only platform powering content operations
By Industry


Tecovas strengthens their customer connections
Build and Share

Grab your gear: The official Sanity swag store
Read Grab your gear: The official Sanity swag store