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 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:
- Single File Project
- 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:
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!
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
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.
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.
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:
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!
14 thoughts on “Maybe it’s buried where you put it!!”
I was looking for info on file location in Studio and … here it is! The right thing at the right time! Excellent explanation and perfect timing, Paul, thank you.
Excellent… glad this was useful for you Enza.
thanks, great article (again)!
I have also sent the link to the German u-cat mailing list (which you haven’t listed in your warning message ;-)) where questions regarding lost Studio files and sdlxliff compatibilites with other TM tools come up quite often.
I hope it’s helpful for them Christine… thank you for sharing it.
One of the most under-estimated features of Studio is that anyone who knows what he’s doing can indeed take the SDLXLIFF file from a project, manipulate it, and put it back. This allows third party developers to come up with smart features that don’t exist in Studio or that are very specific for a customer or project. This processing can be done in an external tool, or, it can be done via the Open Exchange platform. This is one of the reasons why, despite all competition, not any other CAT can beat Studio.
First, I must confess that I didn’t know it was possible to add new target languages to an existing project.
You don’t wanna know how often I created a new project just because the client said “Sorry I forgot: please translate it to this language as well”!
Always nice to read your posts, even more if this time my first thought before reading it was that I woulnd’t learn anything… I was wrong!
Also, I agree with you about using the default project location for freelancers.
But for small agencies I think it makes more sense to create the projects under the Client folder. There are 2 reasons:
1.- Other in-house translators and proof-readers can access the project in Client folder. I know… I could create packages to be sent internally, but it’s an extra step.
2.- Backup process is easier too. I know everybody could run their daily backups in their own PC, but I think the safest point is to act as if they won’t do it, and go for a central point for backups, which is again the Client folder in the network.
2 powerfull reasons to hassle with entering a new network path for each project.
BTW: the default path for projects could be added as a setting in Studio. I’d bet many translators would choose their own path. Dont’ you agree?
How about medium/big agencies with more than let’s say 10 Studio licences, and maybe using GroupShare? I don’t really know, maybe they prefer the default path…
… Jesús Prieto …
Yep, adding a language is simple. In Language Pairs you add as many as you like and Studio will prompt you to prepare the files when you close the Project Settings… glad I was able to tell you something you didn’t know!
I can see your point with a small Agency, but I think GroupShare is a better solution and then you can stick to the same default locations on the local machines and continue taking advantage of the defaults. Back up would be just adding one location… but again, I guess this is all down to personal preference. I would always work with defaults and then this also provides the added advantage that everyone always knows where things are. I can see your point when you don’t use GroupShare though… not all CAT tools will allow you to share projects like this without a server solution so I guess the inconvenience of folder navigating is a small price to pay.
Despite everything I said, if I had some say over what happens in the product I’d add the ability to have default locations set for everything anyway, and an option to always revert to the default or use the last saved location. I think this simple change would then satisfy everyone.
regarding the default Location for the Studio Projects:
In my opinion C:Users[USERNAME]DocumentsStudio [VERSION]Projects is a bit dangerous and I would even recommend freelancers not to keep it.
If you need to reset you Studio settings as described in
http://kb.sdl.com/#tab:homeTab:crumb:7:artId:4393, you must rename
C:Users[User_Name]DocumentsStudio [VERSION] to Studio [VERSION]_Old
Then the links to your projects will be lost. People might even be tempted to delete this folder, as the KB article suggests to either rename or delete the other two folders required for the reset (C:Users[User_Name]AppDataLocalSDL and C:Users[User_Name]AppDataLocalSDL).
This is a good point, and it would be safer if the projects.xml file was also in the AppData folder because this is really the only file you are resetting when you rename this folder. The KB does say rename and not delete, but I see your point and people may not notice the distinction when they read the article. I will ask for the article to be made more clear in this respect. I’ll also suggest to development they make this change… but I have no control over that actually happening!
But despite this it would not change my recommendation. You are talking about a situation where the user misreads the instruction in a KB article designed to correct a problem with Studio not working at all. I don’t think this is a good reason not to take this advice. A better idea is always to make sure you are backing up your work, especially before carrying out any reset operation on your computer. That would go for any application you use and not just Studio.
Beautifully explained as always, Paul!
Finding this article in July 2022, I am wondering how much of this information is still valid now, 7 years later?
Have there been any significant changes in where Studio stores our files?
And if so – is there perhaps a more updated explanation of how this works that you can indicate?
Hi Daniel, I’d say it’s still relevant enough not to require an update. The paths obviously changed as they do with each version but the principles are all still the same.