Open timobrembeck opened 3 years ago
We could actually make this part of a larger log functionality. We could, for example, show page edit events, removed pages, etc as well in this log. Do we want to have a log model or do we derive the log from our version keeping of pages? In this case we would probably need to keep track of exported XLIFFs in a new model.
edit: I'm not sure if a log beyond XLIFF export log is needed. Probably not, as in most cases it is probably only interesting in relation to a specific page. And for this use case we have page histories.
We could actually make this part of a larger log functionality. We could, for example, show page edit events, removed pages, etc as well in this log. Do we want to have a log model or do we derive the log from our version keeping of pages? In this case we would probably need to keep track of exported XLIFFs in a new model.
Good idea! Moving and deleting pages are events which cannot be derived from our current models, so adding an additional log model with different categories could be reasonable.
Interesting: There is already a LogEntry model in django.contrib.admin
...
Using this log has the advantage that all actions are also visible in the django admin UI for debugging... I'm just not sure if we can use it when we deactivate the django admin in production mode.
Motivation
At the moment, the translation managers have to manually keep track which XLIFFs they exported/imported and when.
Proposed Solution
Track these events in the CMS and show a list of the past XLIFF actions either below the page tree inside a spoiler (which is collapsed per default) or on an extra page.
Alternatives
Additional Context
When #1562 is implemented, this issue will probably be solved implicitly.