The beauty of simplicity…

In 2013 I wrote an article called “Solving the Post-Edit Puzzle” which was all about finding a way to measure, and pay for post-editing translations in a consistent way.  Then in 2015 I wrote another called “Qualitivity… measuring quality and productivity” that was all about everything Post-Edit Compare could do but then added many layers of detail and complexity through Qualitivity to support Quality Measurement including a TAUS DQF integration, and incredible metrics that are still not matched by any tool today that I am aware of, and are so good that they are often used to support academic research into translating and post-editing behaviour.

This is all great stuff and I have always been a huge fan of the work that Patrick Hartnett has done on all of the applications he developed over the years.  You don’t often find experienced developers with indepth domain knowledge like this and his apps have always been really relevant to solving problems in the localisation workplace.  So I wanted to bring up and discuss the app that was actually the predecessor to these great apps I just mentioned.  It was also an app that was no longer supported once it’s first successor, Post-Edit Compare, was released.  The app was released around 2011 I think and was called SDLXLIFF Compare.

SDLXLIFF Compare supported Studio 2009 and Studio 2011 and that was it.  After that if you still had it installed you could use it for files from Studio 2014, but probably not for versions after that, and if you didn’t own it then once Studio 2014 was released you wouldn’t have seen it at all.  This was a shame as it was a great app based on simplicity itself.  It doesn’t support the creation of rate tables and calculating the cost of making changes to a piece of work; it doesn’t identify which files have changed and which have not in a project containing hundreds or thousands of files; it doesn’t give you the opportunity to apply quality templates to your work and measure the translation quality; it doesn’t track everything you do, or record the time it takes you to do it.  Rather it does one simple thing… it compares SDLXLIFF files and reports the changes made in a nice simple format.

Why is this beautiful?  Because this is what I believe most users want to be able to do.  Just show me what changes were made to the files so I can see them; and I can send a simple file to another user to show them.  This is all the app does, straight to the point and beautifully simple.  And the good news is it’s been brought back for Studio 2017 so you can download it from the appstore and install it as an sdlplugin.  So it’s no longer a standalone application, rather it runs from within Studio itself, but still does exactly the same thing.  I keep it as a view part ready to spring into action whenever I need to run a comparison… I can drag and drop by pair of files or folders onto the icon you see on the left and I’m ready to go!

A suggested process to work with if you wish to take advantage of this app is as follows.

Single Document Workflow

1. Open your document for translation and pre-translate the file from your Translation Memories and/or Machine Translation
2. Save a copy of the pre-translated SDLXLIFF using the Advanced Save options (or just manually copy the SDLXLIFF in windows explorer):
   
   I would give this a number before the name of the file, or maybe an acronym like PT_ for pretranslated.
3. Work on the original file yourself, or send it off to a colleague for them to work on correcting the translations.
4. Once done save this version as before but with a different name, maybe PE_ for post-edited perhaps.
5. Do this as often as you need and then you will have a collection of versions for using in the comparison.

Project Workflow

1. Create your project, or open your translation package to create a project to work on.
2. Navigate to the target language folders and take a copy of the SDLXLIFF files.  Save them into an appropriately named folder, or
3. Copy the entire project and save it to an appropriately named folder.  The application is smart enough to only compare from the target language folders
4. Work on the project yourself, or send out the files/packages for others to work on.
5. Once you get the return packages or the files back, or when you have finished working on the files, save the project again into a new, appropriately named, folder
6. Repeat this as often as needed so you have a collection of versions for using in the comparison.

The next iteration of this app, Post-Edit Compare, has a nice View built into Studio that supports versioning in Studio so you won’t need these manual steps.  Just one of the benefits of the more sophisticated version that this tool morphed into.  But for most users I reckon SDLXLIFF Compare is enough.

The App.

I’ve created a very short video below so you can see better how this is used but here’s a quick look at the features for now.  First of all the main interface looks like this and has a toolbar and a couple of tabs.  The tabs are “Compare single file” and “Compare directory of files”:

You just select the tab which is relevant and drag and drop your pair of files, or pair of folders into this interface.  The app can use the timestamps to decide which was the original and which is the updated one, but if you’re not sure you can select each one separately.  Once you’ve done that you just click on the little triangle underneath “File” in the menu bar and the comparison takes place.  So as simple as that!

The settings are similarly beautiful.  You have “General Settings” to determine whether you want to show the changes by words or characters; include tags in the comparison; include file information from the original files in a merged SDLXLIFF:

Then you have the “Report Settings” themselves.  These provide some simple options to specify what changes you would like to filter on so the report length can be quite targeted to some extent; they also allow you to ignore files that have not changed at all; and you can change the way the differences are displayed.  I really like this part and wish we had the same feature in the Translation Results window in Studio.  The reports themselves can be HTML or XML, the choice is yours.  I think the HTML is probably more useful for most users but for more technical requirements where you might be pulling the information into another system the XML might be useful too:

Then the last option is “Custom style sheet”.  This supports the use of a custom stylesheet to generate the report so you add in your own logo, or custom colours and layout… you can be as adventurous as you choose.  The only thing is you need to know how to manipulate a stylesheet.  The other thing you’ll need to know is that if you change the format of the output files to XML then a copy of the default stylesheet is created.  Now you can edit that to your hearts content and then point the application to it so your customised reports are used instead:

The end result giving you something like this.  The reports do show a little more information but I think you’ll get the idea and this is perfect fro sharing between your translators, reviewers or project managers for all sorts of reasons that have been discussed in detail in some of the other articles on Post-Edit Compare and Qualitivity:

Finally, if you like the idea, the beauty and simplicity of it all then you can download the application from the SDL AppStore.  It’s free!

Video

I think that’s pretty clear really, but there’s nothing like seeing it in action… so to wrap this article up here’s a short video attempting to show the beauty of simplicity!

Length: approx. 11 minutes