Typically empty segments would be "Not Translated":

So easily filtered.  But sometimes they may be empty and not have the status "Not Translated" in which case it now becomes trickier.  So here you could search for a regex like this in the target:

^$

So also not too tricky.

Elevate Autumn 2021 said:

And ideally also insert a specific content (e.g, a space) into all segments that correspond to your filtering.

That should be simple... or so I thought.  But it's actually not simple because you can't replace the results of a search that finds nothing, with something.

So I have a question here... why is this important?

Tagging two people I'm pretty sure mentioned this in the past...

Jerzy Czopik

Alison Field

Hi Paul, Elevate Autumn 2021,

Interesting. Although the regex works fine in either display filter, it doesn't work in the Find (or Replace) dialog. It doesn't even FIND a target segment containing nothing, using ^$:

I didn't know that. Any other regex I've used in the Find tool has worked OK. For example, a search for ^\s$ works just fine at finding a segment with only a space in it.

Hmmmm! Let me have a think about this...

All the best,

Ali

There are several other situations where the standard Find/Replace regex support "misbehaves". It is frustrating because Find/Replace has some advantages compared with the Display Filters, principally marking the matched elements and, of course, replace functionality.

Anthony Rudd

Perhaps you could provide some clear examples?

One example, that should search for repeated words, matches all words

Another example I had seems to have been fixed.

Anthony Rudd

Indeed... that should work.  Just in case you weren't aware you can workaround this using named backreferences... for example:

\b(?<repeat>\w+)\s+\k<repeat>\b

Thanks for the feedback though, we should fix this as named backreferences are a little more advanced and not all users would know this.

In first place it would be interesting to know, why the segments are empty... For all file types I know the only "empty" content are tags. But I have never seen a segment with zero content having been made available by any file type.

Jerzy Czopik

In reality every filetype is capable of opening up in Studio without any target content.  Of course you can populate everything with TM matches, MT or even a copy of the source.  But in this case I am just trying to answer the question in my mind which is if you have a project containing empty segments, then what's the usecase for adding a space?

I think populating them all is easy, but then how would you know which ones needed to have the space instead of text (assuming this is what's important here).  I guess where the source equalled the target it might be the right ones, but I'd like to understand why this whole thing is needed in the first place.  I think it's probably related to what Alison Field said in the other thread:

https://community.sdl.com/product-groups/translationproductivity/f/elevate/38228/reporting-spaces-in-draft-translation/125220

But I'd like to make sure.

Paul said:

In reality every filetype is capable of opening up in Studio without any target content.

In such cases I always assume something is wrong with the file type. In fact I have never seen an empty segment on source side. I have seen file with no content = no segments. But if there are segments, there is always some content on the source side. The question is, why to put a space on target side instead of proper translation? The answer by Alison you mention in your post may indeed be here the answer, because we are seeing this on daily basis. Also in case someone is translating a PDF directly in Studio or using a crappy conversion there may be a lot of segments which are either badly segmented or do not need translation (dirt on paper interpreted as letters). in such case, however, I would simply at least lock such segments. Then the QA checker would ignore these. But changing to "sign-off rejected" and then locking is really the best way. You can ignore such segments, have them reported as separate category, you see the number of words in such segments in editor and such segments will not be imported in any case in your TM. On top of this such segments will never be changed in any Studio process—translation, revision or sign-off.

Jerzy Czopik said:

In fact I have never seen an empty segment on source side.

Me neither... except when they come from WorldServer where I have seen this before.  But this is not what this question is about.

Jerzy Czopik said:

in such case, however, I would simply at least lock such segments. Then the QA checker would ignore these.

Indeed.  But as I hoped you'd understand, I'm not looking for workarounds, I think I could figure them out.  I'm interested in why they are even needed so we can see what the importance is for changing the behaviour in Trados Studio so a workaround isn't needed in the first place.