Relation handling in general ============================ It is important to consider that the mode (free vs connected) is not only to be considered on a page/language label, but also on a record-type level. For instance it does not make sense to run the model "ProjectStatus" in free mode. Specifically for relations this is important, because if a record-type is in connected mode, any relation has always to be created to the default language. Consequences ------------ This has consequences on the translation behavior when translating relations. Options in connected mode: * Relations need to be replaced completely in the translation. So the original can have 3 related records and the translation only 1. (eg contact persons or product price - keep in mind that those may themselve be in connected or free mode again, so it depends on their mode what to store in the relation) * Relations must stay the same (eg a relation to a category - again categories may run in free or in connected mode themselves) Options in free mode: Let the user choose on copying whether to copy the relations or not? Mixture of record-type modes ---------------------------- An example is having ext:news records which may be run in free mode, while the categories may be in connected mode only. In relations always the uid of the default language record must be stored for connected record-types. Specifics for media records --------------------------- (Assuming connected mode here.) I would consider images to be handled in the second way (must stay the same). Yet a sys\_file\_reference must be translatable, in order to allow to exchange the associated image in a translation (a different sys\_file is referenced in the translated sys\_file\_reference) Specifics for "insert record" and FE "content slide" ---------------------------------------------------- Since this brings arbitrary records into the space of the target page, it has to be *defined* how translations are handled. The user may pick any record (eg content element) from any page, independent of the mode the source page is running on. Including a connected record into a free mode language, would require to split up the connection. Including a connected record into a conected mode, would require to import the default and all translations. Including a free record into a free mode is easy. Including a free record into a connected mode language is only possible if the language of the free record matches the default language of that page. Open ToDo: How to handle inclusion of records with language "ALL"? The usecase "content slide" is subject to the same problems. The exact behaviour needs to be specified. Which fallback rules do apply? The ones of the requested page, or the ones where the content is stored? In collect mode: Collect all of the same language or apply fallback at each level? Editor experience in BE ======================= In general it is ok to allow content translation only on pages, where the page itself is translated into the target language. This concept might be wrong for sysfolders though, which is often used as a content-container and the records are included somewhere else. It must somehow be possible for the editor so see in BE what will eventually be visible in FE. So the FE language rules must actually be removed from TS and moved to a page TSconfig that is used in FE as well. (It is totally unclear to the editor what it means if an alternative page language is hidden, but non-hidden records in that language exist.) The deflangbinding pageTS option must be the default for connected mode and the option itself must be removed. Localized displaying of records ------------------------------- For connected record-types it makes sense to display the records in the BE user's chosen language. For instance, a user with BE language being set to FR would appreciate it to select a category by its FR translation. (Even though the reference to the default language is stored to DB underneath due to the connected nature of category translations.) This would also be nice for the page tree. If a translation to the selected BE language does not exist the default language shall be displayed. (I consider a fallback chain as overkill for this purpose.) Data storage ============ Locales ------- I opt migrate away from language\_uids to locales ASAP!! (We have a usecase where we have a global folder with custom records and its translations and then serveral websites, which should use those data. Only now that some websites have a different default language, which breaks the whole system!) Storage of connected data ------------------------- I would strongly recommend to switch the strategy how connected data is stored from "merge on select" to "unroll on store". That means an excluded field would not be empty in a translated record, but would actually hold the value of the default language. This "unrolling" must happen recursively over all relations of a record on every change. Reasons: - The usecase of a CMS is 99% select statements. If we optimize data to be fast on select, we gain a lot of performance. - Overlay on select would get superfluous - We can actually sort on translations natively in the database - We do not need to implement the various wizards to connect/deconnect since the data is already there Handling of language ALL ======================== Storage wise this would be represented as an empty locale, as the data has no language. Such records must not be translatable. Translation of sys\_file and related =================================== I would by no means connect sys\_file to a locale or make it translatable. sys\_file is an index and an abstraction of filesystems nothing more. What must be translatable is the metadata of a file (sys\_file\_metadata) and the relations to a file (sys\_file\_reference). As written above, the referenced file of a file reference may be changed in a translation, like the title would be. The file meta data need an additional field, which declares the locale the meta data are written in. A description of a nice portrait, stored in sys\_file\_metadata, must have a language definition as there is no concept of a default language. Page translations and content translations ========================================== It is very important to precisely define how page translations influence a) content selection in FE b) content editing in BE! Especially the meaning and consequences of enable fields of translations is mostly unclear to editors, integrators and even Core devs.