Translation should not begin by copying another entry
Adding a translation to a work should not require copying its identity, collections, relationships, and community, then trying to reconnect the duplicate to the original. In REZICS, an object that must endure first becomes a Unit. The same Unit can natively carry several content languages, while books, media, software, Posts, Realms, and people add their own product capabilities on that foundation.
Every localization retains an explicit language while sharing a stable ID, relationships, permissions, and history. Languages are semantic peers rather than one required primary language. A reader can request a language directly or receive the best available presentation through their preferences and the Unit’s fallback order.
What is available now
- Preserve several content languages in one stable Unit, carrying names, summaries, descriptions, bodies, and images as each product requires.
- Resolve presentation through an explicit choice, reader language preferences, and the Unit fallback order, with a way to switch to other available languages.
- Search through names and aliases in each language and generate server-rendered localized SEO metadata and structured data.
- Keep collections, follows, relationships, reviews, and Realms pointing to one identity rather than a language-specific copy.
- Preserve each language’s revision content within one shared history while retaining contributor, permission, and governance context.
Keep original and translation communities in one context
Original content, sources, and work relationships can remain on one Unit while translators add or revise their own language presentation there. Readers do not need to follow a second entry, and existing booklists, tags, reviews, and communities benefit directly. A translation community or Realm can develop its own collaboration practices without taking the work identity away.
Sharing a Unit does not flatten differences. Each language still has its own content and revision path. The next translation workflow will also record the source language and source revision on which a translation depends, so an original update can mark translations for review without declaring one language the permanent absolute original for every kind of content.
Available foundation and next workflow
People can already add, edit, order, and remove content languages; resolve a presentation from reader preferences or an explicit language; and emit localized metadata and structured data for safely public Units. Multilingual SEO presentation itself is available. The remaining discovery gap is a Unit sitemap and language-version enumeration that let search engines find these presentations systematically.
Translation proposals, review and publication states, source-revision and stale indicators, language-scoped access management UI, translator and reviewer credit, and source-update notifications are still expanding. This layer should make translation communities effective without replacing the shared work with disconnected copies.
Relationships and boundaries
Language presentations of the same work stay on one Unit. When a language edition has a distinct publisher, license, format, content, or release lifecycle, it should become a Release or variant Unit with an explicit relationship back to the main work. A source URL only says where content appears; it does not replace work identity or prove ownership.
A Unit is neither a translation-memory tool nor generic JSON. Shared identity and multilingual capabilities belong on Units; fields truly unique to books, Posts, Realms, and other products remain on their extension models.