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).

Erik Freitag

I've messed around with this for a while now and it seems the only way to handle this is to identify where segments don't have a non-breaking space (QA check) and then manually add them in with the Quick Insert.  I tried using the export for external review, and also retrofit, by making the changes in Word, but this doesn't work.  Not too clever really.

I guess, if your target is a DOCX, that you could do the search replace in Word afterwards.  This is straightforward enough, and then you could align the original source with the corrected target to get an updated TM if needed.

Frustrating this isn't easier to achieve, and I guess pretty irritating your translators didn't use non-breaking hyphens as they worked... or was this all MT and now you have to correct?

I'll take a look with the appstore team and see whether we can do something simple for things like this.  A search and replace to support tags would be quite interesting to look at.

Erik Freitag

I've messed around with this for a while now and it seems the only way to handle this is to identify where segments don't have a non-breaking space (QA check) and then manually add them in with the Quick Insert.  I tried using the export for external review, and also retrofit, by making the changes in Word, but this doesn't work.  Not too clever really.

I guess, if your target is a DOCX, that you could do the search replace in Word afterwards.  This is straightforward enough, and then you could align the original source with the corrected target to get an updated TM if needed.

Frustrating this isn't easier to achieve, and I guess pretty irritating your translators didn't use non-breaking hyphens as they worked... or was this all MT and now you have to correct?

I'll take a look with the appstore team and see whether we can do something simple for things like this.  A search and replace to support tags would be quite interesting to look at.

Indeed, search and replace with tags would be nice.

Just to clarify: I'm the translator, not the proofreader. Due to requirements imposed by the end client (a large national body), translators are supposed to use non-breaking hyphens a lot, and as if that weren't enough, often in places where they are unnecessary, illogical or even outright wrong.

I'm just looking for a way to make my life a bit easier with this. I predict that nobody would complain if I were to use non-breaking hyphens exlusively, hence the idea to use search and replace.

Erik Freitag

Erik Freitag said:

Just to clarify: I'm the translator, not the proofreader.

Ok... I only just completely understood your original post!  So none of this would be required if you used the tags as you translate.  Can you perhaps reprogram the keyboard so that your dash symbol uses the Ctrl+Shift_OemMinus, or use AutoHotkey for that?

Still interested to look at the search & replace thing, esecially since you can 100% expect your proof reader to pick these up as they won't be non-breaking spaces at all.  What seemed to work before when I responded to Bruno over 3-years ago definitely doesn't work for me today.

Paul said:

So none of this would be required if you used the tags as you translate.  Can you perhaps reprogram the keyboard so that your dash symbol uses the Ctrl+Shift_OemMinus, or use AutoHotkey for that?

That's not very practical for another reason I haven't mentioned: The projects from this customer include a huge amount of fuzzy matches, which do not use the required non-breaking hyphens (due to the fact that they often come from an anlignment process). I'd really like to get rid of the need to manually alter those hyphens, as that's exactly the kind of menial task software in general is supposed to be good at.

Good to know that your original solution doesn't work any longer, thanks for letting me know, so I can spare the effort to try this further.

Hi Paul,

Sorry for getting back to this issue after such a long time, but it still is costing me a lot of time. Hence my question (which may only be losely related and a MultiTerm question instead): Is there a way to include non-breaking hyphen tags in MultiTerm entries, so I can at least make sure I don't have to manually edit those afterwards?

Many thank in advance,

kind regards,

Erik