Hi Jesse Good 

I think this may fall into the category of "good bugs" as opposed to a "bad bug"!!  Although it's worth asking the question as I may be denying the team credit where it's due for a planned feature rather than a fluke.  I'll ask the team.

Unknown said:

Seems it's not a bug at all! It's a feature that was added and not documented publicly. It works for these filetypes only and this is deliberate:

Microsoft PowerPoint 2007-2016
Microsoft Word 2007-2016
Microsoft Excel 2007-2016
HTML 4
HTML 5
Json

OMG! If this is hardcoded and works the exact opposite than current functionality, then it's EXTREMELY BAD!!!
That would be a definite "NO" to this update!

From this description it looks like a hasty and not properly thought-through "fix" for the issue reported in the other thread I referrenced :(

Hi Jesse,

Since 2011 as a minimum. As Katerina O. stated here www.proz.com/.../232756-studio_2011_save_target_but_only_translated_segments.html you can just change segment status to any other (with Signed Off as an example) to this effect.

Unknown said:

Hi Evzen Polenka,
It's been known since Studio 2011. Check out this thread, post by Katerina O. of 17 Sep 2012: www.proz.com/.../232756-studio_2011_save_target_but_only_translated_segments.html

The current behavior (empty target segment resulting in source string being put in generated target file; any other content in target segment resulting in that very content being put in generated target file... all that regardless of segment status) dates way back to old Trados times when there were no segment statuses at all... segments could be only "empty", or "containing something".
And that's perfectly logical and consistent behavior...

Unknown said:

perfectly logical and consistent behavior...

Logical is when you deliberately leave a segment empty and it remains empty. Logical is when you deliberately copy source to target and it returns source as target. 
But when you deliberately lock empty segments and they are returned populated, it is totally far from being logical...

The current behavior is logical from the CAT tools functionality perspective. CAT tools have behaved like this for years. And there is perfect logic behing this - CAT tools are NOT "content creation tools", they are just translation tools. Therefore, if you load source file and then do nothing - i.e. all target segments are left intact, i.e. EMPTY - and you generate target file, you get file with original source text. You DON'T expect to get completely empty target file... you expect a file containing "result of the translation"... and since you have NOT done any translation, you get a file containing the SOURCE texts.

Similarly, when you translate only SOME segments - and leave the others empty, without putting any translation in it - you expect only those SOME segments to appear translated and the remaining ones again containing the SOURCE text, NOT EMPTY.

This IS perfectly logical, CAT tools do this for years and no one had ever any problem with this.

Unknown said:

This IS perfectly logical, CAT tools do this for years and no one had ever any problem with this.

With all due respect Evzen I don't think you're in a position to know this or make this claim.  Whilst you and some others found a solution there are plenty of others who did not.  The changes made were the start of an effort to support this in a logical way (I know you don't think this is very logical) and once all filetypes support the same one I think it provides a good way of controlling the behavior with consistency.

Unknown said:

This IS perfectly logical, CAT tools do this for years and no one had ever any problem with this.

If I were you, I would not state it in such a dictatorial way. Not all 'CAT tools for ages..." (mQ leaves empty target segments empty by default; you need to run a specific command [Copy source to target where empty] to make it do what you describe in caps as a must) and not 'no one had ever any problem'. Otherwise this question would never arise.

Unknown said:

Otherwise this question would never arise.

If you mean this thread, then read the original post again - this question is actually about surprising NEW behavior... The original poster actually expected the "good old" behavior (source text), but got empty segment instead.

There seems to be some confusion in this thread, so just to make it clear.

In Trados Studio 2015 or earlier:

When you set an empty target to "Translated" and generate the file, you get the source text.
I have verified this with my own copy of Trados Studio 2015.

In Trados Studio 2017 SR1:

When you set an empty target to "Translated" and generate the file, you get a blank (nothing).
I have verified this with my own copy of Trados Studio 2017 SR1.

What this means, is the behavior has changed from previous versions.
Now I haven't tested Trados Studio 2017 pre-SR1, but I think the behavior is the same as Trados Studio 2015 or earlier (i.e. the change started with SR1 or later).

To be precise - the old behavior (2017 pre-SR1 and earlier) does not depend on the segment status at all, and is therefore very simple to understand and perfectly transparent.

EDIT:
And what I see as especially alarming is that this drastic behavior change appeared absolutely silently, without a single word about this change in any official What's new in Studio 2017 SR1 changelog, etc. So silently that even Paul did not know about it, as this thread shows.
(Yes, it was introduced already in SR1, not only in the CU8 beta)

What you mean by saying this

Unknown said:

...does not depend on the segment status at all...

Status is exactly what it depends on. It was discussed 5 years ago (for ver. 2011). Didn't you read the link I cited? Or you don't believe those people? 

You do not necessarily need to select 'Translated' (unless it is sort of ultimatum). Select any status (Signed off, Signed off rejected, Translation approved, Translation rejected - your choice) other than 'Draft' or 'Not translated'. => Empty remains empty. Since 2011. That's it. 

Now, with 2017, if an empty segment is confirmed (status 'Translated'), it remains empty. If you leave it unconfirmed (status 'Draft'), the source text is inserted in the target file. My version is 14.0.5821.4 (half year before SR1). 

Keeping in mind that such confirmed [but still empty] segments do not go to TM, finally I can say it works as I most expect it. And I appreciate it, no matter if it was introduced deliberately/silently or by omission/mistake.

Hi Jesse Good 

Unknown said:

1. Is it documented anywhere?

Only internally.  I don't know why this didn't go in the release notes.

Unknown said:

2. What files types currently have this behavior?

I'm sharing exactly what we have written up internally:

======================

Requirements for translating empty target segments

I. Filters for bilingual files (XLIFF, GDF, Bilingual Excel, etc.)
The content from the target segment, whether it is empty or not, will always be written as it is in the target file, regardless of segment pair status and the contents of the source segment.

II. Filters for non-bilingual files
For this type of filters there are 2 different situations, according to the segment pair status:

1. Segment pair is not confirmed
This case represents all the segment pair statuses except Translated, Translation Approved and Signed-Off.

Outcome: the source text is copied into the target file.

2. Segment pair is confirmed
This case represents the segment pair statuses Translated, Translation Approved and Signed-Off.

Outcome: the source text is not copied into the target file, leaving the text empty.

Notes:
Other segment properties such as lock status or match percentage must not affect the rules above.

Out-of-segment content is not subject to these rules.

Filters which USE this processor as described are these:

• Microsoft PowerPoint 2007-2016
• Microsoft Word 2007-2016
• Microsoft Excel 2007-2016
• HTML 4
• HTML 5Json

======================

So if you are getting the same behaviour with other filetypes can you share some examples with me?  I just spoke to the filter manager and there have been no changes in this area so it would be good to validate them and understand what's happenning.

Thank you

Hi Paul

Great answer!

I also get this behavior with XML files, here is a simple XML file if you would like to test it out.
Just throw this in any project, set the status to "translated" and then generate the target translation.

<?xml version="1.0" encoding="utf-8"?>
<IllustTrans>
<Content>hello</Content>
</IllustTrans>

Thanks Jesse Good , I see what you mean. I knocked up an InDesign and Framemaker file and these also behave the same way. So I have gone back to the development team and will confirm the outcome when I know. In some ways it makes sense to have consistent behaviour like this across all monolingual filetypes... but let's see what the team thinks.