Maybe it’s buried where you put it!!

Projects, packages, segmented SDLXLIFF files, unsegmented SDLXLIFF files, source files, target files, Translation Memories, Termbases, AutoSuggest Dictionaries… are they buried deep in your computer by Studio without you knowing?  Are you really subjected to a message like the one on the left?  Sometimes the posts in the technical forums make it seem that way, but I think it might not really be like this, so in this post I want to take a look and see how all these things work.  I have discused many of these things in the past here and there, but now seems a good time to consolidate all this into one article and try to explain the workings of Studio with regards to file locations.  Let’s start with Projects.

Studio Projects

Studio has two kinds of Project.  Why two, that’s confusing already?  Well there are two because one is created automatically while offerring you a very fast way to translate a single file into one target language (the language you are translating into), and the other involves you going through a Project creation process where you can have as many files and folders as you like and as many target languages as you like.  So we have these two:

1. Single File Project
2. Standard Studio Project

Technically there are more types of Project than this but essentially, if you’re working with the desktop tool and storing your files locally (on your own computer) there are really only these two.

“Single File Project”

The “Single File Project” is created in the background when you use the Translate Single Document command and it creates a series of files like this in the same location as your source file (the one you’re translating):

My source file was a DOCX and if I use this method for working two files are created.  An SDLPROJ file, which is the Project file containing metadata telling Studio useful things about your translation file such as the language pairs, the filetype settings to be used, the analysis bands, where the Translation Memories and Termbases are that you’re using in this Project, your customised verification settings… and lots more useful information.  But what it doesn’t contain is the translation!  The translation is in the SDLXLIFF, sometimes referred to as a “bilingual file”.  You’ll also note that the SDLPROJ and SDLXLIFF files when you work this way are saved using this convention:

source filename.source file extension_language pair.filetype

A very important thing to note when you work this way is that when you save your target language file it will be written into the same folder again, and with exactly the same filename as the source.  So be careful and don’t just click ok when you save target or you’ll overwrite your original source file.  I always add a t_ to the beginning of the suggested name and then save it when I work this way, and then I know which file is which and I never overwrite anything.

One of the really cool things about Studio is that you can share this SDLXLIFF around and other users can open this file in Studio and work on it.  If you were using special settings that are in your SDLPROJ file then sharing the SDLXLIFF on it’s own means that the user you shared the SDLXLIFF with won’t get all the nice settings you do.  It also means that if the other person is using a different version of Studio to you, or even another TEnT (Translation Environment Tool), they might be able to translate the SDLXLIFF but you should carefully check it when you get it back because there may have been features in your original SDLXLIFF which are not supported by an older version of Studio, or a different TEnT.  The other important point to note is that if you share the SDLXLIFF on it’s own then depending on the filetype used to create it, another Studio user may not be able to produce a target file.  They can probably translate it, and may receive a few warning messages about no quick inserts and missing filetype, but they won’t be able to generate the target file.  To ensure complete compatibility you need to create an appropriate Project package or share the Project through SDL GroupShare, but these methods are only possible with the Professional Version of Studio.

“Standard Studio Project”

The “Standard Studio Project” takes a copy of your source files (you can combine filetypes and have as many as you like) and creates a Project structure in a location of your choosing.similar to this:

The source language folder, in this case en-US contains a copy of the original source files, and an unsegmented SDLXLIFF for each file.  There is no target language associated with the SDLXLIFF files in this folder.  The reason for this is because Studio uses these to create more target languages really quickly if you have to add them later on.  So if you are sharing the SDLXLIFF files you don’t share these ones.

The four target language folders, fr-FR, hu-HU, it-IT and ja-JP, contain fully segmented SDLXLIFF files and the translation for each language is placed into the respective folders.  These are the SDLXLIFF files you can share with others.  When you create the target files once the translation is complete they are saved in these folders too.  So all your translations and their respective bilingual files are neatly organised and saved by language here.

So you can keep your source files in your preferred folder structure, safe in the knowledge they will not be overwritten or deleted, and the Translation Project is separate.  I have had conversations with users in the past who really want to keep these projects in the same folder as their Client files so they can easily find them in the future.

I’d recommend not to do this because it means you are always having to change the path to the Project location, and if you forget to change the path then Projects end up where you don’t want them.  So perhaps a better idea is to create a shortcut to the SDLPROJ file and place it in your Client folder as shown on the left.  If you don’t know how to do this just right-click on the SDLPROJ file in Windows Explorer and select  “Create shortcut“.  This creates a new file called “Shortcut” and you can copy this into any folder you like.

If you work this way you have all the information your client sends you saved in your neat folder structure and completely safe from the operational work of the translation.  If you remove the Projects from Studio to clear up the Projects View then all you have to do to find it again is navigate through your well known and understood filing system, double click the shortcut to the SDLPROJ file and the Project will be reloaded into Studio… simple!

Breaking news! If you have Studio 2015 installed then there was an update released via Studio 2015 CU3 which provides a mechanism to have the flexibility you might prefer without it being a bad idea!!

Now, why do I think it’s a bad idea to save the Studio Projects into your client folders?  Well, the first time you run Studio (this example is based on Studio 2015) it will suggest that you create these Standard Projects into the default location which is here:

c:Users[USERNAME]DocumentsStudio 2015Projects

Studio 2011 will go into the Studio 2011 folder, and Studio 2014 will be in the Studio 2014 folder, so pretty straightforward.  You can’t go wrong and your Translation Projects will always be saved in the same place without fail, and you will be able to easily add this single location to your regular backup procedures in case of hardware failure.  It also means you are using the software the way it likes to work, and this is always a good way to avoid problems if you can live with it.

But what happens if you decide you don’t want to put your Projects in these nice, straightforward and oprganised locations?  Still straightforward, you just need to change the path when you create your Project in here:

The next time you create a Project, Studio will use this new location.  So changing the default is simple, you just use it!  If you decide to put the Projects into a folder structure based on your Clients then obviously you’ll have to remember to change the path every time you do it and if you do this a default location is a waste of time anyway because it’s always changing!!  The other thing you’ll have to do is rewrite the Project name at the end of the path every time you change it.  If you keep the path as the default then you don’t have to change the path each time, and you only have to write the Project name in the “Name:” field.  So in my screenshot you can see the Project name is missing from the end of the path in the location field and I’ll get a message like this if I don’t manually add the name to the end of the path… quite irritating and somewhat confusing when you don’t know why you see this:

One thing I didn’t mention, is that if you do save to a location that you didn’t want and you can’t find the Project files then don’t forget you can get to the location from the Projects View in Studio by clicking on the “Open Project Folder” icon in the Home ribbon, or right-click on the Project and choose the same option from the right-click context menu.  So you’re never really lost when the Projects are listed in the Projects View:

If you removed the Project from the Projects View, and you didn’t create a shortcut in your Client folder and you can’t remember where you saved it… then you’re on your own and not even a PSMA with SDL will help 😉  You just need a good search engine!

Packages

At the start I said that technically there are more than two types of Project and “Packages” are another.  They are really the same as a Standard Studio Project in terms of how they behave with the file structure, but I’ve written about packages in the past so I’ll direct you to this article where you’ll note I gave the same advice about saving the Project that is created to the default folder… fortunately!!  Packages comes from Studio, WorldServer and SDL TMS and they all work the same way, you open the Package using the “Open Package” command in the toolbar and you’ll be given the opportunity to decide where the Project is created like this:

Perhaps the only difference between this and the “Standard Studio Project” is that the Package could contain Translation Memories, Termbases and AutoSugest Dictionaries – any or all of them.  When this happens the structure of the folders in your Project are a little different because additional folders are created to contain these resources like this:

Now you can see three additional folders that have been created in your Project structure when you open the Package.

– AutoSuggest Dictionaries
– Termbases
– Tm

All of this makes complete sense because they need to go somewhere, and like this everything is neatly ordered so you know where to find them.  The SDLPROJ file also gets a date/time stamp appended to the original name.

When you open the Package and save the Project in your chosen location this is also saved in the same location you saved it last time by default, so again the behaviour is consistent and easy to work with.

Other resources

Finally I added this section because I wanted to cover the use of your own resources, like your Translation Memories, Termbases and AutoSuggest Dictionaries.  Where does Studio put these?  The answer is it doesn’t!  When you add any of these resources to your Project, no matter what kind of Project it is, Studio just points towards them and leaves them where you put them… well ok, there is one exception I can think of.  If you create a Project Translation Memory during the Project creation process then Studio will create a folder called Tm and place this newly created Project Translation Memory inside the Project folder structure as we saw with the Packages.  But your main Translation Memories are always left where they are.

Finally again…

I wanted to finish this off with one thing that I get asked a lot.  “If I move the Projects in windows explorer to a different location will Studio know where they are?”  The answer to this question is no.  Studio writes the location of the projects into a file called the projects.xml which you’ll find here:

c:Users[USERNAME]DocumentsStudio 2015Projectsprojects.xml

If you have 2011 or 2014 it’ll be in the same location for the Studio 2011 or Studio 2014 folders.  If you move the Projects around in Windows Explorer Studio has no idea you did this or where you put them, and depending on the version of Studio you use you’ll see a different reaction.  Studio 2009 will probably have a heart attack and throw all kinds of error messages about being unable to find files, Studio 2011 (fully patched) will gracefully remove it from the Projects View and won’t complain, Studio 2014 might tell you the location of the project is not available when you close the application, and Studio 2015 will just gracefully remove it from the list without complaining because it can’t find it anymore.  But none of them know where the Projects are once you move them.  For that to be possible Studio would have to be scanning the Projects identified in the projects.xml at all times, either when Studio was closed or when it starts up, and then search across your entire computer to see if it can find where you put them.  Trust me, you don’t want that but maybe someone could create an app for it!!!!

To add them back into the Projects View if you do move them all you have to do is open the SDLPROJ file from the new location and that’s it.

I hope this clears up some of the mysteries that seem to prevail and that you’ll be able to find your most effective way of working with files in Studio… if you knew all this already I hope it was an interesting read… and if I missed anything out, or you have questions please post them in the comments and I’ll update the article to make it more useful in the future!