4

I know that when you localize a component, you create a new one with its own history. We have had complaints from users that they have localized and translated components and later on, they have "reverted" back to the blueprinted version. That unlocalization removed the "new" component and you have lost all data on it.

Is there anything.. anywhere where you as an "admin" can check to see 1. IF the item really was localized by someone 2. If so - who/when can it have been unlocalized?

I know you can check the database for "new components" by users and so forth - but any ideas if it is even possible to check out? Business users complain but how to prove them right/wrong?

Improve this question
2
  • It might that users are right and wrong, meaning it's a fair expectation to see this history but there isn't an easy way to get it back after unlocalizing. Some things that might help: opt to roll back changes rather than unlocalizing--you don't get the latest shared version of the Component, but this keeps the history (use the Create a new version option); if using translation management, translation memory will help translators "re-apply" the same translations; or I've seen extensions to "push" or "pull" changes between BluePrinted versions, which would keep history as well.
    – Alvin Reyes
    Jan 2, 2015 at 23:31
  • And if the users are fairly motivated, they could request a product change and vote for it through Tridion Ideas. They might gets some support since users typically outnumber their technical counterparts.
    – Alvin Reyes
    Jan 2, 2015 at 23:34

1 Answer 1

Reset to default
2

There is nothing built-in to be able to report on this. Once you unlocalise the item, all details on the localsed version are lost.

Depending on your logging level, this information could be written out to the Content Manager logs. However, it would not be a nice job sifting through them, and you'd have to retain all of the log files to get an accurate view.

You could write some Event System code to handle the 'Unlocalise' event and then log the version history (of the localised item) into a separate data store (or App Data on the item) maybe.

Improve this answer
5
  • 2
    I like the idea to log the item into a separate DB. This could be an SQL Server database or SQLite (local) file-based DB. Also, I would suggest using a simple ORM like ORMLite to read/write the data.
    – robrtc
    Dec 23, 2014 at 10:43
  • I seem to recall that there was an "audit trail" extension for Tridion 2011, partly to show how trivial such an extension would be to implement. But I can't find it anywhere. If somebody has better Google skills than me, can they post a link?
    – Frank van Puffelen
    Dec 23, 2014 at 20:52
  • Here is the link: code.google.com/p/tridion-2011-reporting. Captures all the CMS eventing data and stored in MongoDB (NoSQL).
    – Ram G
    Jan 2, 2015 at 16:13
  • App Data would be good if you want this history to travel with the item (history doesn't normally content port). If using a DB, then also keep in mind if you want history across DTAP servers (one DB per CMS server?).
    – Alvin Reyes
    Jan 2, 2015 at 23:17
  • Chris Summers also wrote a manual process for commenting: code.google.com/p/tridion-2011-power-tools/wiki/ItemCommenting.
    – Alvin Reyes
    Jan 2, 2015 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.