Make relations untranslatable

[Taitava]

What's this about

Currently only simple data fields can be untranslated. In some cases it could be handy if relations could be made constant across different translations.

For example, say that we have a HomePage object that is translated to English and Spanish. The HomePage has images called CarouselImages linked together via a $many_many relation. The images should be global, meaning that there is no need to have different image sets on both language versions of the HomePage. Same images should be displayed on both HomePage versions.

Currently, if a user goes to add new images and/or remove old ones, the changes are only reflected to one language version, and the user needs to do the same again for the other language version.

This is something I'm now opening this discussion for in order to start planning how this improvement could be implemented in this module. I can't make any promises about anything, though.

Many to many relations

When a relation is changed (= new relation created, old relation deleted, or any of the relation's extraFields changed), copy the relation record in the database and make it point to all translations.

Many to one and one to one relations

These are problematic. I think that in these relations, it is unfortunately mandatory to clone the objects that are linked to the translated object, because there is no separate cross table that would allow us to just clone the relation without cloning the data.

Another way would be to hook to the translated object so that every time a relation is accessed (either a read/write operation), instead of returning the current object's relation, we would borrow the relation from a "master object" (read: the default language version) and return that instead. In other words, every time a relation of an English or Spanish object is either read from or written to, we return the English object's relation, because in this scenario we would use English as our default language.

These are just my thoughts and I can't guarantee that they are actually implementable in practice.