What 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:
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