Numbers and alphanumeric strings not being auto-substituted consistently

 Hello,

 

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

 

We have 3 TMS for a customer:

  • DEU-ESP
  • DEU-RUS
  • DEU-ENG

 

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.

 

ENG:

RUS:

ESP:

 

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,

 

Madeleine

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:

    ENG:

    RUS:

    ESP:

     

    The other ESP example:

     

    Thanks again,

    Madeleine

  • In reply to Madeleine Barois:

    Hi,

    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.

    Daniel

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

    Best,

    Madeleine
  • In reply to Madeleine Barois:

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

    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  >
Related