Good bugs… bad bugs!

01What the heck is a good bug? I don’t know if there is an official definition for this so I’m going to invent one.

An unintended positive side effect as a result of computer software not working as intended.

I reckon this is a fairly regular occurrence and I have definitely seen it before.  So for example, in an earlier version of Studio you could do a search and replace in the source and actually change the source content.  This was before “Edit source” was made available… sadly it was fixed pretty quickly and you can no longer do this unless you use the SDLXLIFF Toolkit or work in the SDLXLIFF directly with a text editor.  In the gaming world it happens all the time, possibly the most famous being the original Space Invaders game where the levels got faster and faster as you killed more aliens.  This was apparently not by design but it was the result of the processor speed being limited, so as you killed the aliens the number of graphics reduced and the rendering got faster and faster… now all games behave this way!  Another interesting example in the Linux/Unix world is using a dot at the start of a filename to hide it from view.  This was apparently a bug that was so useful it was never “fixed”.

All this brings me onto my next point.  If you found that a particularly “good bug” was so useful that you built a process around it because it solved a problem you’d been unable to resolve before then you could be more than a little disappointed if it was “fixed”!  So these “good bugs” may often turn out to be opportunities for “features” rather than “bugs”.

This brings me onto the reason for this article which is that a “bad bug” was brought to my attention today, and as I was investigating it I discovered it was potentially a “good bug”. I say potentially because it needs a little work to become a “feature”, if indeed it doesn’t get “fixed” first!

So, here’s the “bad bug”.  When you create a project in Studio with multiple files and haven’t merged them during the creation process then you can still merge them with virtual merge at any time.  This is a cool feature, everyone loves it, but what you may not have noticed (and I didn’t either) is that every time you do this a temporary file is created in your local temp folder… so in here:


So for example, I open a project containing these files below and open them all up together with the virtual merge:


When I create this project I can see that temp files are being created in this Temp location, and when I open them all up together and press Ctrl+S to save this creates a much larger temp file.  So now I see something like this where the larger file is the temp file for all the files I’ve opened in a virtual merge:


Now this is where the “Bad bug” comes in.  If I have Auto-save in use then every time the save kicks in that large file at the top is saved again, and again, and again, and grows in size as I work through the translation.  When I close Studio many of these temp files are deleted or just become zero byte files, but not these big temp files.  They just stay there filling up my hard disk until I run some software utility that clears out the temp folders.  So the “Bad bug” that needs to be addressed is that Studio is not removing these temp folders when we’re done and have closed Studio down.  We don’t need them because the Auto-save feature saves the files in the AutoSave folder over here:

c:Users[USERNAME]DocumentsStudio 2015AutoSave

So if I’ve already got the files saved in the AutoSave then the temp files are useless right?  Until now I would have thought so, but this is where the “good bug” kicks in.  The virtual merge in Studio allows you to open many files at once, but if you wanted to then share the merged file, which many people do, then you cannot.  If you try and save it you get separate SDLXLIFF files, one for each of the SDLXLIFF’s you opened in the merge.  Even the AutoSave files are separate, one for each of the individual files in your project.

If you take a copy of that big temp file that was created and add .sdlxliff to the end you can open it in Studio.  Once open it you’ll see that it contains all the merged files just as if you’d either merged them when creating the Project or opened them all up together with the virtual merge.  So the temp files that are created are actually the very files Studio cannot create through the UI, and that many users are looking for so they can send them out for translation as a single file.  That was an interesting find indeed, although maybe it’s a deliberate behaviour that has a “bad bug” associated with it!

This has a useful implication because as a Project Manager I could even add them to my project so they could be handled in a package and used to update the translation memories and pretranslate the original files when done.  I have been able to save the target files from these temp files so pre-translation of the originals might not even be necessary, but as this is an unintended benefit I’m wary of relying on the temp files for the final files as matter of principle.  So if I create a folder for the temp files in my project and then drop them into the folder after adding the .sdlxliff extension I’d have something like this now:


So an interesting “Good bug” with an unexpected benefit which might be useful until the development team either “fix” the bug, or turn it into a feature.  In reality I think that even if the bug is fixed you might still be able to use this method to get at the temp file, but you’d have to make sure you do it as soon as you opened the files in Studio as they might not be there anymore once Studio is closed!

Just in case you got to the end of this and still don’t see what I’m getting at then here’s a short video to explain the process.  In the meantime my parting comment would be “enjoy the good bugs while you can!”

Approx. 7 minutes 25 seconds

0 thoughts on “Good bugs… bad bugs!

  1. Thanks to Yuji Yamamoto for having pointed out this “bug” and thanks to Paul for having taken Yuji’s request seriously and investigated it. Without your eagerness to find out what was going on behind the scenes, we might never have discovered this “feature”.

  2. Funny enough, just a few days ago I cleaned up my Temp folder (…AppDataLocalTemp) wondering why there’s 5 GB of data in there! Now I know. Thanks Paul. Regarding “bug” or “feature”: I would also say that these files are definitely useful, but for the “normal” Trados the current procedure of making use of them presents a very big hurdle.

    1. Indeed it does, although it’s not too tricky once you’ve done it a few times, but I agree with you that this should really be a feature on the product and not a workaround. So let’s wait and see what happens in the future.

  3. Hi Paul

    I don’t know if I can reach you by replying to a post notification but here I try.

    I follow your blog and find it very useful – good job you do. Now, there’s a problem I’ve been dealing with for a long time, and I was hoping you could help me. It is about alignment and more specifically about the segmentation rules. If you’re willing, I would describe in detail.

    Kind regards from Tallinn, Estonia


    1. Hi Martian, the best place to ask these questions is in the Community forums. We have our own and I spend a lot of time in there learning and helping, so if you post in there it would be much better. These threads are not the best place for it.

  4. Great tip! I’ve missed this function very much. I tried to use the SDLXLIFF Toolkit for it but couldn’t manage it (maybe it’s not even possible). Thanks a lot!


    1. Hi Mats, I don’t think the toolkit can do this… it might be possible but only under certain circumstances because of the options needed to do this. The merged file you’d get would also not allow you to save target files as it puts the files together for a different purpose. We are going to be doing some work on the toolkit for early next year (want to integrate it into Studio as a plugin) so might have a think about this too.

  5. Hi Paul,
    This is a cool tip! It might turn out to be useful.
    I take this occasion to ask something I probably asked in the past in the Communuty, but if I I cannot remember the asnwer… While I do have AutoSave enabled, my c:Users[USERNAME]DocumentsStudio 2015AutoSave folder is always totally empty. So where are my auto-saved files?
    Thank you.

    1. Hi Marco, good question… but I don’t know! Maybe set the auto-save for one minute intervals and start work, and just keep an eye on the folder. If nothing is in there I’d recommend you raise a ticket so we can investigate it further with you.

      1. Hi Paul, this is weird: I changed AutoSave settings from 10 minutes to 1 minute and it worked. I then reverted it back to 10 minutes (which is the interval I prefer) and it now works also with 10 minutes. In any case your tip worked 🙂 Thanks!

    2. Hi Marco

      The files are indeed in the folder you mentioned, but they are purged as soon as you either save or close the SDLXLIFF file in the Editor. If you set the interval to a short time (1 or 2 min.) and make some changes to the file without saving it, you will see the AutoSave file coming up in that folder.

      1. Thank you Walter, I was aware of that. But the auto-saved files had never been there (I checked that folder now and then, after making changes and before saving or closing the SDLXLIFF file in the Editor) until I changed the AutoSave interval to 1 minute. Even after reverting back to 10 minutes, the auto-saved files are now there as expected.

  6. I have now done some exploring, and like Marco, I see no auto-saved files in the AutoSave folder… Actually, nothing has been saved there since 30 October! But unlike Marco, I cannot “re-start” this process by changing the autosave interval. (The temp saving procedure works, though.) Does anyone have a suggestion about this?

    (I do, now: I deactivated the auto-save function and then activated it again, and now it works. But talk about bugs! Obviously it has not worked for more than a month! Luckily — and obviously — I did not need it during that time.)

    Additionally, I can say that the Help text information that “the AutoSave folder, located at the same place where you save your project data” is not true — that folder is *always* located where Paul says it is.

    And while we’re at it, can anyone (Paul?) explain the meaning of the folders with names like “fbce434b-28c1-49df-8a32-4e4e58fba62e” in the AutoSave catalog, and the meaning of folders like “{35611519-658B-4964-934C-261808F8DCE0}” in the Temp catalog? Opening them is not much help, since the contents varies. (I don’t think it’s important, but it certainly is mystifying.)


    1. Sadly enough, this does not work either at mine. Might it be because I have 2 hard disks, and I save all projects on d: and not on c: as standard? Does anyone have an idea?

      AutoSave is empty.

      What is more: there is no such file in the temp directory as mentioned above. What I see is a new folder with the source text in source format (i.e. .xls) but under another name.

      Anyway, Paul, thanks ever so much for one very important sentence of you video:, explaining why I regularly could not generate target files, since some documents were missing. I changed this configuration in my antivirus software application and hopefully, this issue will be solved :-).


Leave a Reply