The empty segments will be sent through to the target file and now you need to clean it up. You could probably have guessed it, particularly if you were used to implementing the Edit Source workaround in the past: If I merge the segments so I now have a complete sentence that will be simple to handle what will that do to the target file: If you merge across paragraph units and then save your target file what will that mean for your target document, and are you able to do anything about this before you send the file to your customer? Let’s take a look at two examples, the first in Word and the second an XML file. This brings me back to where I started in describing the initial reluctance to support this in Trados products.
Trados studio 2017 autosuggest not showing up manual#
So it’s basically an automation of the manual workaround, which does save a lot of time, and it has the additional benefit of locking the segment and setting the status to whatever you like automatically. If I disable the option to Hide empty segments that have been merged in the Automation settings then you’ll see this: If you pay attention to the segment numbering you’ll see that #2 is not there anymore at least it’s not visible anymore. Now it looks as though I was able to do this with a simple operation and no longer have to deal with the empty segment… but this is not the case. In Studio 2017 you no longer need to use Edit Source to achieve this you simply enable the feature to merge across paragraph units, which is disabled by default, and you can then merge these same segments to achieve this: So now you have dealt with the problem of merging with this workaround, but you are left with an empty segment in #2. The image below explains the way you used Edit Source to resolve this by enabling the feature in the Project Settings first and then editing the segment, in this example #2, cutting it to your clipboard and then pasting it into #1. One of the reasons many users wanted to edit the source was so that they could resolve poor segmentation, there are other reasons of course, but I’m focusing on this one. So think back to the days when you could not edit the source in Studio either. I wanted to write about the concept behind this so that it’s clear what is happening when you use this new feature in Studio 2017. 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. 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. 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. 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. 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. Ever since Trados came about one of the most requested features for translators has been merging across hard returns, or paragraph breaks.
0 kommentar(er)
