Hi Bruno,

It's a little tricky as non-breaking hyphens in Studio are usually inserted with a tag from the quick insert toolbar.  But you can do a search and replace if you first insert the tag, like this:

Then copy paste the tag into the search and replace... it will look like this:

So very difficult to see any difference.  But when you search/replace the target will now all have non-breaking hyphens.  At least it worked for me and my target file did not break at the hyphens anymore.

Regards

Paul

Hi Bruno,

It's a little tricky as non-breaking hyphens in Studio are usually inserted with a tag from the quick insert toolbar.  But you can do a search and replace if you first insert the tag, like this:

Then copy paste the tag into the search and replace... it will look like this:

So very difficult to see any difference.  But when you search/replace the target will now all have non-breaking hyphens.  At least it worked for me and my target file did not break at the hyphens anymore.

Regards

Paul

Hi Paul,

I've tried this, but isn't there any way to do this in a way that will show those as tags in the target segment as well? I am expecting my proofreader to correct all these instances (literally hundreds of them) and mark them as an error...

MTIA,

Erik

for SDL Trados Studio version 2017, it is still there "Home > QuickInsert > 3rd small Icon"

and

if you want change "this" into "that" (vice versa) is a kind of simple job even for several hundreds of them.

regards

Erik Freitag

Why is it necessary for these to be a tag?  Can't they be search/replaced across the entire file in one or two goes?  Probably I'm missing some context from your question which would help me to provide you with a sensible answer.

Thanks for your quick reply!

They don't need to be a tag per se, but they are when I insert them via QuickInsert (and also when they come from the TM). They need to be recognizable as non-breaking. With the method you propose, they are indistinguishable from regular hyphens, which is why the proofreader will mark them as errors.

Erik Freitag

I haven't tested yet... but couldn't you create a QA check to find them?  Then if any were missed from a global search & replace it would be trivial to spot them as the QA check would flag them.

Even if I could do this, I can't tell the proofreader how to do their work. Shouldn't non-breaking and regular hyphens be clearly distinguishable? How is my proofreader (who is working on the SDLXLIFF) supposed to know whether I've used a regular or a non-breaking hyphen in any given case?

Erik Freitag

That's a good point of course.  How do you tell in Microsoft Word?

The answer I think, is you can't.  This is probably why Studio uses a tag for this.  I think your best bet is to use a QA check and report on normal hypens in the scenario you need them and then Studio will flag them so the proofreader can make the correction:

Do you have an example of the scenario you're dealing with?

In Word, regular and non-breaking hyphens do look different when you toggle the "Show/Hide" function (i.e. they differ in Show mode, they're the same in Hide mode).

By "example of the scenario", do you mean an SDLXLIFF file?

Erik Freitag

Well... I had no idea until you said that.  So I magnified them a lot and I can indeed see the difference:

Would be a real stretch for me to spot these in a real text though!

An sdlxliff would be perfect so it has a few examples of the sort of things you need to find... helps to play with the rules a bit and try to come up with something sensible.

Maybe this depends on the version of Word or some display settings, but I can see the difference without any problem at 100% magnification. I use this regularly (although I agree that a more prominent solution would be nice, simlar to regular vs. non-breaking spaces, but that's an issue with Word, after all).

Basically, I'd be happy to be able to replace any and all regular hyphens in a given text with non-breaking ones, as I rarely encounter instances where a non-breaking instead of a regular hyphen would do any harm. It'd be much easier to manually replace wrong non-breaking hyphens with regular ones than having to do it the other way round (hence my trying to do a search and replace).