aazzoma khateeb

The default rules will handle this and should give you an idea of how to improve it if you wish:

Or you can use more distinctive approach by adding individual rules for the htmł element.

This would be for example

<b> </b> as tag pair with no extra segmentation hint, but with selected feature "Tag acts as word end" (is really VERY important when translating and should be selected by default, dear SDL)

<br> as placeable with the segmentation hint "exclude"

and so on...

I find this regex-based approach rather amateurish, cumbersome and most importantly failing big time with just a little bit more complex HTML code, not mentioning anything more complicated (containing entities, comments, inline scripts, etc.)

Therefore I use a simple script which exports the HTML content to very simple XML structure like this

<string cell="A1">blablabla, some complicated HTML code</string>

This is then easily processed using the XML with HTML embedded content, with all comfort of embedded content parser.

And then it's again very easily injected back into the appropriate places into the original Excel sheet using another  rather dumb script which only reads the cell location from the XML element attribute and puts the string in the cell.

Not a method for average Joe Translator, I know...

Why not then simply save Excel as XML and process that in Studio? Not that complicated as it seems...

Not usable with multilingual Excels - where target (or rather multiple targets... like 15 languages or so) is to be placed to other cells than the source.

Not usable with multilingual Excels - where target (or rather multiple targets... like 15 languages or so) is to be placed to other cells than the source.

Indeed. I have rarely to deal with such, sorry - this is why I usually go the easiest way for a freelancer.