Daniel Hug 

I can only hazard a guess that the reason is that [\d-]* could match absolutely nothing, effectively finding "matches" in places where you might not expect or want them, like between every character in your text or at the start/end of a string.  It really doesn't make sense to do this, and if we did it could lead to some very odd results, so Studio probably doesn't support zero-length matches.

Notwithstanding that, how do you convert a zero-length match to a tag for embedded content?

 Patrik Mazanek may have a better explanation if I've guessed incorrectly.

 Daniel Hug 

I can only hazard a guess that the reason is that [\d-]* could match absolutely nothing, effectively finding "matches" in places where you might not expect or want them, like between every character in your text or at the start/end of a string.  It really doesn't make sense to do this, and if we did it could lead to some very odd results, so Studio probably doesn't support zero-length matches.

Notwithstanding that, how do you convert a zero-length match to a tag for embedded content?

 Patrik Mazanek may have a better explanation if I've guessed incorrectly.

Paul Filkin 

I would have expected Trados to just ride over the zero-length matches and convert all normal matches. I guess that would be more robust and less puzzling for the user?

Daniel

Daniel Hug 

I don't think ignoring the fact there are zero-length matches there is appropriate.  How would Studio know when you intended this and when you didn't?  I think I would expect a more concise regex to avoid all doubt.

But I can see your point.  Skipping zero-length matches could make regex more accessible for general use but there are advanced use cases where the ability to match or recognize zero-length strings is valuable and necessary for precise text manipulation and analysis.  Adding an option could take care of that... but then anyone who used them in the first place may not know what such an option was for and wouldn't benefit from it in the first place ;-)