Six years since the original post, and still not fixed...
and Paul has been finding out when this will get addressed for two years

That's... well... beyond impressive!

Krzysztof Konatowicz

Krzysztof Konatowicz said:

and Paul has been finding out when this will get addressed for two years

That's... well... beyond impressive!

Indeed :-(  I don't have a good excuse... it's easy to track these issues when reported through a support contract, but very difficult when they are not.  We do try to always include the dev reference numbers these days and this helps, so I hope I do a better job of getting close to impressing you in the future.

First of all.. I dug out the item and to make it easier to find in future it's under our reference CRQ-15108.

This ticket has been closed after some work was put into Studio 2019 SR2 CU5 to resolve part of this... the update TM and auto-propagation were fixed, but there is still a remaining issue that is not being investigated any further.  I've summarised the remaining problem here.

The remaining AT concern does not relate to what goes in the TM, but rather what is generated by an AT result. For a segment like "100–250 °C.", when there is no TM match, extended handling of non-translated content introduced in an earlier enhancement now means an AT proposal is generated, specifically "100-250 °C." Here, the standard dash is used; the proposal does not copy whatever dash is used in the target language. This is because there's no guarantee that punctuation conventions in the source language will be the same as those in the target language; they often differ, or (say) use single-width characters in one and double-width in the other, etc. The primary function of a TM system is not to generate a perfect AT proposal when there is no match in the TM, it's to recall saved translations. In this case, once a translation with the desired dash has been saved to the TM, AT proposals are no longer generated for the segments concerned, and instead, 100% matches are returned with the saved punctuation.

The workarounds suggested are:

1. some detailed maintenance of the TM to remove incorrect entries
2. Use the find and replace in Studio:
   Find -> \-(\d*) (the hyphen is used here)
   Replace -> -$1 (the minus is used here)

That's what I can conclude from the ticket.  If you are testing I suggest you only do this with a currently supported version of the product, preferably 2021, because anything still a problem in an older version won't get addressed at all.

Krzysztof Konatowicz

Krzysztof Konatowicz said:

and Paul has been finding out when this will get addressed for two years

That's... well... beyond impressive!

Indeed :-(  I don't have a good excuse... it's easy to track these issues when reported through a support contract, but very difficult when they are not.  We do try to always include the dev reference numbers these days and this helps, so I hope I do a better job of getting close to impressing you in the future.

First of all.. I dug out the item and to make it easier to find in future it's under our reference CRQ-15108.

This ticket has been closed after some work was put into Studio 2019 SR2 CU5 to resolve part of this... the update TM and auto-propagation were fixed, but there is still a remaining issue that is not being investigated any further.  I've summarised the remaining problem here.

The remaining AT concern does not relate to what goes in the TM, but rather what is generated by an AT result. For a segment like "100–250 °C.", when there is no TM match, extended handling of non-translated content introduced in an earlier enhancement now means an AT proposal is generated, specifically "100-250 °C." Here, the standard dash is used; the proposal does not copy whatever dash is used in the target language. This is because there's no guarantee that punctuation conventions in the source language will be the same as those in the target language; they often differ, or (say) use single-width characters in one and double-width in the other, etc. The primary function of a TM system is not to generate a perfect AT proposal when there is no match in the TM, it's to recall saved translations. In this case, once a translation with the desired dash has been saved to the TM, AT proposals are no longer generated for the segments concerned, and instead, 100% matches are returned with the saved punctuation.

The workarounds suggested are:

1. some detailed maintenance of the TM to remove incorrect entries
2. Use the find and replace in Studio:
   Find -> \-(\d*) (the hyphen is used here)
   Replace -> -$1 (the minus is used here)

That's what I can conclude from the ticket.  If you are testing I suggest you only do this with a currently supported version of the product, preferably 2021, because anything still a problem in an older version won't get addressed at all.