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

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.

Paul said:

But as I hoped you'd understand, I'm not looking for workarounds, I think I could figure them out.

Sorry, Paul, please forgive. In my world I have to know as many workarounds as possible to cope what customers demand in terms of time and quality. So I do not expect the tool to be able to cope with any possible problem that may arise from the crap we get for translation. To some extent it is possible to foresee what may be wrong, as for example the possibility of merging segments over paragraph boundaries, but there are limits. And for such limits or borderline situations I need workarounds.

Paul said:

But as I hoped you'd understand, I'm not looking for workarounds, I think I could figure them out.

Sorry, Paul, please forgive. In my world I have to know as many workarounds as possible to cope what customers demand in terms of time and quality. So I do not expect the tool to be able to cope with any possible problem that may arise from the crap we get for translation. To some extent it is possible to foresee what may be wrong, as for example the possibility of merging segments over paragraph boundaries, but there are limits. And for such limits or borderline situations I need workarounds.

Jerzy Czopik

So you don't think there a usecase for being able to search replace nothing, with something?  I don't want a workaround, just an answer to this question.

Paul Jerzy Czopik

You're right Paul, from my perspective the usecase would be more or less the same as in the other thread. 

For whoever asked the question in this thread, there obviously is a usecase for being able to search replace nothing, with something. Would it be possible to program the Find and Replace tool to recognise ^$ or is that too difficult? I'm presuming that these questions were asked remotely and that you don't know specifically who asked them in order to find out what their particular usecase is.

I have never received a job that had lots of segments with no translation that needed to be filled with a space. I'm trying to imagine when that would be a usecase but can think of nothing, apart from a poor quality PDF as described by Jerzy but in that usecase when translating, I would tidy up the source .docx file before translating in a new project. If, as has happened, I received a translation to proofread that had been translated with all the rubbish still in the file, ideally I would still use a new .docx file and pretranslate it using the translated content, before then proofreading it. If for some reason I couldn't I would be looking at each individual segment anyway and, when populating the first instance of a segment that needs just a space to prevent the source from flowing into the target document, a space is successfully autopropagated to all the repetitions so that would work fine for me.

Therefore, I don't see a usecase for being able to search replace nothing with something that would be pertinent to my usual workflow.

Thanks,

Ali

From my point of view there is no such need. I haven't seen such use case since my very first beginnings with Studio back in 2009. But this is only my personal view, and obviously I cannot know all use cases.