Why are field-level translations not recommended for PortableText?

The recommendation against using field-level translations with Portable Text in Sanity is primarily due to attribute count concerns.

Why Field-Level Translation Objects Don't Work Well with Portable Text

When you use the object-based approach for field-level translations (where each language gets its own field like title.en, title.es, etc.), Portable Text content creates a massive number of attributes in your dataset.

Here's why: Portable Text is inherently complex. Each block, span, mark, annotation, and decorator creates its own attributes. When you multiply this by multiple languages using the object approach, you quickly hit Sanity's attribute limits.

For example, a simple Portable Text field might create attributes like:

• content[].children[]
• content[].markDefs[]
• content[].style

With field-level objects for 3 languages, you'd get:

• content.en[].children[]
• content.es[].children[]
• content.no[].children[]
• (and so on for every nested property)

This exponentially increases your attribute usage with each additional language.

Better Alternatives

The document-internationalization plugin documentation explicitly recommends document-level translations for Portable Text content. This means:

1. Separate documents per language - Each language version is its own document, linked via references
2. Independent publishing - You can publish translations as they're ready
3. No attribute explosion - Each document has its own set of attributes

The Array Exception

If you must use field-level translations with Portable Text, the internationalized-array plugin is a better option than objects, as it uses fewer attributes by storing the language identifier in the _key field rather than creating separate object properties for each language.

However, document-level translation remains the recommended approach for any content-heavy fields like Portable Text.