Handling of files and language variants
Currently, there is no possibility to provide variants of a file in TYPO3. The often cited example is ‘I have an image with text in it’. Now this image should be used in several language variants, only the text differing. Another example is the PDF document featuring the same content, but being available in different languages.
This situation is currently solved by editors by just creating CEs in free mode (without relation to the translation parent) and relate the corresponding file in requested language.
To improve this handling, files and their corresponding metadata records can be handled and related in a different way, that enables editors to stick to actual translation of records and will respect file variants by current language.
Here is the proposal:
Please note, this approach will not follow the usual overlay approach the core follows, but will use a copy mechanism.
- introduce a new database field named file_source into both sys_file and sys_file_metadata tables. Additionally, sys_file will receive the field sys_language_uid.
- translating sys_file_metadata is already possible in the filelist module.
- creating a new file record (by upload or import) will set the sys_language_uid to 0, thus default.
- translating the sys_file_metadata record will present a new upload field. Here the editor may upload the language variant to be used in this specific language. Transparently in the background, the original files uid will be saved into the variants file_source field. The same data will be saved for the sys_file_metadata record. So if a language variant file exists, the file field of sys_file_metadata will point to this variant, not the original file anymore.
- the editor creates a CE with FAL field in default language and references some files. The selection will only present files that are in default language as well, no variants are displayed.
- then a translation of that CE is initiated, copying the references in the background. Overlaying fields from sys_file_metadata (of that language) are still editable.
- rendering of the language variant in frontend will look for a difference in file_source and file fields of the sys_file_metadata field of the referenced file. If one is detected, the language variant of the file is used, otherwise the original.
- Usage of free mode for creating translations of CEs, that only differ for their related files, can be avoided.
- File variants become an option for editors, working experience will be enhanced.
- database migration takes care of copying data into the newly introduced database field.
- a switch will preserve the current behaviour for exisiting installations
- backend module will support resolving free mode translations into translated records.
- more consistent behaviour of translated record
- enhanced user experience for editors
- behaviour change
- existing instances need to be migrated
- manual action might become neccessary for existing instances which wish to use the new behaviour
Remarks and notes
A possible migration step would be a switch for enabling the current behaviour, even with the feature in place. That is needed during transition, until the current situation using free mode and independend file records is resolved and the relation between files is established. There is no way to do that automatically, but the user has to provide information.
This work should be supported by a backend module the core provides. Here is how it should work:
- Walk all pages and find free mode CEs in different languages, that contain different sys_file_references records and display them side by side.
- Provide a selection mechanism to relate the original files to the language variant.
- In background, the sys_file_records will be updated to the structure mentioned above.
- the CEs will be integrated to be translated again, no longer free mode.
- CE can be waifed from display, if the free mode should stay as is.
Topic Initiator: Anja Leichsenring
Topic Mentor: Anja Leichsenring