I think it sounds a bit scary, that for every entity + entity revision table, there would need to be an entity translation + entity revision translation schema too to support revisions for translations (which would be a must for core stuff that already supports revisions, so we cannot really forgo that). The later issue says it should be discussed here. Looking at #1498668: Refactor file entity properties to multilingual and #1498674: Refactor node properties to multilingual, I'm a bit concerned about how this interacts with revisions. ability/ease of keeping data integrity/consistency.We still need to fully understand the pros and cons of this storage model. | nid | vid | langcode | default_langcode | title | uid | status | created | changed | comment | promote | sticky Remaining tasks entity_property_revision: stores revision of revisable entities, same schema as PK: nid, vid, langcode.entity_property_data:entity id, revision id, language, all entity properties (e.g.entity: entity id, revision id for revisioned entities, bundle, entity language (original submission language for the entity).The system will need to support the ability to mark each property as translatable individually and the ability to switch a property's translatability.Īs a side issue, we probably need a better term than translatable, possibly multilingual (see #1498850: Rename the 'translatable' field property).
Another reason is that both involve the concept of Entity variant and addressing them together should allow us to find a unique and consistent solution. We want to address translation and revisioning together since D7 does not fully support those combined, even just for fields (see #12 for details). Fields can store per language and revisioned values.