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?

  • 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 '15 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 '15 at 23:34
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.

  • 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 '14 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 '14 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 '15 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 '15 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 '15 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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