One of my favourite features in Studio 2017 is the filetype preview. The time it can save when you are creating custom filetypes comes from the fun in using it. I can fill out all the rules and switch between the preview and the rules editor without having to continually close the options, open the file, see if it worked and then close the file and go back to the options again… then repeat from the start… again… and again… I guess it’s the little things that keep us happy!
I decided to look at this using a YAML file as this seems to be coming up quite a bit recently. YAML, pronounced “Camel”, stands for “YAML Ain’t Markup Language” and I believe it’s a superset of the JSON format, but with the goal of making it more human readable. The specification for YAML is here, YAML Specification, and to do a really thorough job I guess I could try and follow the rules set out. But in practice I’ve found that creating a simple Regular Expression Delimited Text filetype based on the sample files I’ve seen has been the key to handling this format. Looking ahead I think it would be useful to see a filetype created either as a plugin through the SDL AppStore, or within the core product just to make it easier for users not comfortable with creating their own filetypes. But I digress…
Ever since Trados came about one of the most requested features for translators has been merging across hard returns, or paragraph breaks. Certainly for handling the translation it makes a lot of sense to be able to merge fragments of a sentence that should clearly be in one, but despite this it’s never been possible. Why is this? You can be sure this question has come up every year and whilst everyone agrees it would be great to have this capability, Trados has not supported it through the product. The reason for the reluctance is that when you merge a paragraph unit (the name given to translation units separated by a paragraph break) you probably need to be able to decide how this change to the structure of the file should be handled in the target document. Sometimes this might be simple, other times it might not be, and the framework that Trados products use is not designed in a way that supports the ability to alter the look and feel of the target file across every filetype the product can open. Even the release of the Studio suite of products still uses the same basic idea of being able to handle the bilingual files directly rather than importing them into a black box and whilst this does offer many advantages, this problem of merging over paragraph units remains… until now.
“More power to the elbow”… this is all about getting more from the resources you have already got, and in this case I’m talking about your Translation Memories. In particular I’m talking about enabling them for upLIFT. upLIFT, in case you have not heard about this yet despite all the marketing activity and forum discussions since August this year, is a technology that is being used in SDL Trados Studio 2017 to enable some pretty neat things. I’m not going to devote this article to what upLIFT is all about as Emma Goldsmith has written a really useful article today that does a far better job than I could have done. You can find Emma’s article here, called “
I was playing around with 
In my world you’d have to be on another planet not to know that Studio 2015 was released this week. The release is very good and contains lot’s of new features, many of them translators and project managers have wanted for a long time. In fact even if you did know it was released you might be one of the users who’s still wondering what’s in it, how do you get it and install it, how it affects previous versions, how you migrate your data, how you use your Studio 2014 OpenExchange Apps. etc. Lot’s of practical questions that you might not be able to readily find the answer to. So, first things first! 
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. 
It’s funny how questions seem to appear like London buses… you don’t get any and then they all come at once! More often than not it’s very specific questions that behave this way too. So you don’t see them for ages and then you get the same question in a number of places for a day or two and then it goes quiet again! One of the topics that falls into this category is changing the view in the Editor. By this I mean the colour of the text, the font types or the background you’re working on. All these things can be changed in Studio to make it easier if you’re dealing with documents that don’t display well and you want to work in wysiwyg mode.
The AutoSuggest feature in Studio has been around since the launch of Studio 2009 and based on the questions I see from time to time I think it’s a feature that could use a little explanation on what it’s all about. In simple terms it’s a mechanism for prompting you as you type with suggested target text that is based on the source text of the document you are translating. So sometimes it might be a translation of some or all of the text in the source segment, and sometimes it might be providing an easy way to replicate the source text into the target. This is done by you entering a character via the keyboard and then Studio suggests suitable text that can be applied with a single keystroke. In terms of productivity this is a great feature and given how many other translation tools have copied this in one form or another I think it’s clear it really works too!