Versions and Localization are incompatible together

[DallasO]

When a collection has versions enabled and has localized fields, a new version is saved for changes to any locale.

For projects using these features together, this requires keeping x desired * N locales number of versions, a majority of which are unusable restore points because they are missing locale data.

On top of requiring more copies than necessary to support the desired retention policy, this can easily confuse users who have to dig through multiple versions to find what they may be looking for.

In my specific case, users write content in English, and a hook translates that content into the other locales. In a majority of cases, that means I only need 1 new version when English is changed, and the rest of the locales could be saved to the same version.

As far as I can tell, there is no easy way to remove intermediate versions as the last to save has latest: true, but the only difference between the other versions is date and content. Using date or content could work, but seems flaky.

My suggestion is to add the ability to append changes to the latest version. But maybe others have a better solution.

[hardikkaurani]

This feels like a real architectural mismatch between the versioning model and localized content workflows rather than just a minor edge case.

Right now, versions appear to operate at the document-save level, while localization effectively turns a single logical content update into multiple sequential writes. The result is:

• inflated version counts
• fragmented restore points
• unnecessary storage growth
• confusing version history UX

In workflows like the one you described, the issue becomes even more obvious because the non-English locales are derived/generated content rather than independently authored changes.

So instead of:

EN save -> version
FR auto-translate -> version
DE auto-translate -> version
ES auto-translate -> version

what users conceptually expect is more like:

Single content revision
└── contains all locale updates

I think your “append to latest version” idea is actually pretty reasonable, especially if implemented as an opt-in strategy.

Something along the lines of:

versions: {
  drafts: true,
  localizationStrategy: 'merge-locale-updates'
}

or:

saveLocaleToLatestVersion: true

could potentially solve both:

• retention inefficiency
• fragmented restore history

without changing existing behavior for projects that rely on per-locale version granularity.

Another important point is that the current behavior creates restore points that are only partially meaningful. A “version” that only contains one locale update often does not represent a coherent document state from a content-editor perspective.

That weakens one of the main goals of versioning systems:

• reliable historical snapshots
• understandable revision history
• safe rollback points

I’d also be cautious about trying to clean up intermediate versions manually after save hooks. As you mentioned, once version metadata like latest: true starts getting involved, post-processing becomes fragile quickly.

Long-term, this probably needs framework-level awareness that:

• localization updates may belong to the same logical revision
• automated locale writes differ from independent author edits
• version history should optimize for restore semantics, not raw write events

Especially for translation-heavy CMS workflows, this could otherwise scale poorly both operationally and from a UX perspective.