The current translations flow and data storage has a few issues which makes it confusing for content editors. It was created with rendering speed in mind, but in so doing, created limitations to how a content editor would ideally like to interact with the system.
Some general thoughts:
Doc translations should have a publishing flow tied to the doc. A content editor should be able to save/edit/import translations and have it automatically be put into a "draft" state for previewing. When the doc is published, the translations are published along with it.
There should be a concept of "global translations" which stores all of the UI-related strings used by the site and isn't necessarily tied to a particular doc. The "global translations" should also have its own draft and publishing states and is fetched on every page render.
When listing docs in a collection, it is often useful to grab a subset of translations from those docs. An example is listing the latest N blog posts for display on the home page. We may only need the "meta title" and "meta description" translations. There should be some concept of being able to aggregate translations into a collection which contains a subset of translations for fields in that collection.
When a page is rendered, these translations need to be fetched in a deterministic way that doesn't cause "waterfall" RPCs. If you're rendering, Pages/index, mode=draft, for example, you should be able to configure a data fetch in a single batch request that includes: the draft data for the page, draft translations associated with the page, "global" draft translations, recent blog posts, and draft translations for "blog meta title/description".
Note that this task is meant to only solve how we should configure the backend / db for an efficient, non-error-prone publishing flow that is also fast when rendering websites. Once the data storage is solved, we'll need to wireframe how we'd like users to interact with the system in straightforward, intuitive ways.
Description
The current translations flow and data storage has a few issues which makes it confusing for content editors. It was created with rendering speed in mind, but in so doing, created limitations to how a content editor would ideally like to interact with the system.
Some general thoughts:
Pages/index, mode=draft, for example, you should be able to configure a data fetch in a single batch request that includes: the draft data for the page, draft translations associated with the page, "global" draft translations, recent blog posts, and draft translations for "blog meta title/description".Note that this task is meant to only solve how we should configure the backend / db for an efficient, non-error-prone publishing flow that is also fast when rendering websites. Once the data storage is solved, we'll need to wireframe how we'd like users to interact with the system in straightforward, intuitive ways.