Numbers and alphanumeric strings not being auto-substituted consistently



We're having issues with auto-substitution in Studio 2017. Here's an example:


We have 3 TMS for a customer:



All 3 have identical Recognize settings, Penalty settings, and Auto-substitution settings.





All 3 have been re-indexed and had their fuzzy index statistics recomputed.


The TUs that compose these TMs are from translations of identical DEU source files.


Now we have a new project, for which the source file is the same for translation into ESP, RUS and ENG.


However, when we attach the TMs, it seems that the auto-substitution function only works sometimes.






When we looked up this ESP segment in the ESP-DEU TM, the measurement cited in the segment was "1,5 mm2" and not "2,5 mm2", so it seems like the auto-substitution was indeed successful in this case - only for ESP.


However, for ESP there are other examples of auto-substitution of measurements/alphanumerics not being auto-substituted properly, ex:



Are there language-specific variables that we're unaware of that might affect the behavior of the auto-substitution function (and, by extension the analysis results)?


Thanks in advance for your help,



8 Replies Latest Replies: 14 Jan 2019 11:09 PM by Paul < 1   2  >
  • Hi

    Can you provide a better screenshot of these images please? It's a little too small for me (eyes are getting bad!) and I can't see if there is any reason for this behaviour or not and I can't mock it up as I'm not sure what to use.
  • In reply to Paul:

    Hello Paul,

    Thank you for your response. Yes, my apologies, I didn't realize the quality on the images was so bad. Here they are again, let me know if they're more legible now when you click to expand them:


    The TM settings:




    The auto-substitution examples:





    The other ESP example:


    Thanks again,


  • In reply to Madeleine Barois:


    I am experiencing the same. It was not like this before:

    Maybe a bug came in with 2019 SR1? I would love to hear from SDL about this.


  • In reply to Daniel Hug:

    Hello Daniel,

    That's interesting that someone else has the same issue, thanks for the example. Let's see if has an idea about what might be going on.


  • In reply to Madeleine Barois:

    any news on this issue? I de-installed the Number Verifier Add-on, but that did not help, so I re-installed it.

    EDIT: This is really a problem for us, so I kept working on it. I am now pretty sure that is has to do with what characters are adjacent to the number. If the character is not considered a separator, the number is not replaced properly or something like that? The substitution behavior changes when I enter characters into "Alphanumeric custom separators".

< 1   2  >