Another note:

After updating the TM from the alignment I mentioned above in 3), the TM shows the metadata that I input with the alignment update. But the numbers do not match the documents I used for the alignment - they seem to have reverted back to the segment in the TM with the next-lowest numerical value (I aligned QL 120 tablets / 25 days and the unit in the TM with the metadata from that alignment show QL 6 tablets / 21 days).

Melissa Wurst

Just in case you are not aware of the details about how TM works:

Normally (i.e. if you don't turn this off explicitly), the TM engine is able to recognize certain tokens in the sentence... tokens like numbers, dates, times, measuring units, etc.
And the segment in TM then does not store the ACTUAL VALUE of the token (like the number 6 or 21), but stores only the "the token goes here" information. However, the original value is still displayed to the user...

So, when the TM shows you "30 g / 25 days", it in fact contains "<number> <unit> / <number> days".
And this ensures that sentences containing the same text, but with different numbers, are still recognized as full match against the segment stored in the TM.

But what often happens is that the text is NOT EXACTLY THE SAME, especially when numbers and/or measuring units are involved - very often there are spacing differences, i.e. the spaces between the numbers, measuring units, etc. and the surrounding text are different... typically a normal space vs. non-breaking space.
Typographical rules in many languages require a non-breaking space between the number and units, which the text editing software (like Microsoft Word and the likes) automatically inserts when originally typing the text, but they are often lost when doing additional manual edits like copy & paste, deleting and manual re-typing the values, etc... or when doing edits in various programs (which are or are not configured to insert the non-breaking spaces), or by different people using differently configured programs, etc.

So, you may want to check if the spaces in different segments are really the same as in your TM segments.

Plus, there is always a chance that there is simply a bug in Studio... SDL seems to be doing some internal under-the-hood changes in Studio in the last couple of years, which unfortunately brings various weird bugs, even in parts which worked reliably for years.

Melissa Wurst

Just in case you are not aware of the details about how TM works:

Normally (i.e. if you don't turn this off explicitly), the TM engine is able to recognize certain tokens in the sentence... tokens like numbers, dates, times, measuring units, etc.
And the segment in TM then does not store the ACTUAL VALUE of the token (like the number 6 or 21), but stores only the "the token goes here" information. However, the original value is still displayed to the user...

So, when the TM shows you "30 g / 25 days", it in fact contains "<number> <unit> / <number> days".
And this ensures that sentences containing the same text, but with different numbers, are still recognized as full match against the segment stored in the TM.

But what often happens is that the text is NOT EXACTLY THE SAME, especially when numbers and/or measuring units are involved - very often there are spacing differences, i.e. the spaces between the numbers, measuring units, etc. and the surrounding text are different... typically a normal space vs. non-breaking space.
Typographical rules in many languages require a non-breaking space between the number and units, which the text editing software (like Microsoft Word and the likes) automatically inserts when originally typing the text, but they are often lost when doing additional manual edits like copy & paste, deleting and manual re-typing the values, etc... or when doing edits in various programs (which are or are not configured to insert the non-breaking spaces), or by different people using differently configured programs, etc.

So, you may want to check if the spaces in different segments are really the same as in your TM segments.

Plus, there is always a chance that there is simply a bug in Studio... SDL seems to be doing some internal under-the-hood changes in Studio in the last couple of years, which unfortunately brings various weird bugs, even in parts which worked reliably for years.

Hi Evzen,

Thank you for the insight.

The spacing in the segments is exactly the same (see below - the first screenshot is from the updated document processed in Studio and the second is of the only segment that appears in the Main TM even after I've tried updating it):

I also created a Project TM and it does not seem to have this issue, as it contains all of the following TUs:

I should add that I am approaching this from a project management, not a translation, standpoint.

Melissa Wurst

Melissa Wurst said:

The spacing in the segments is exactly the same (see below - the first screenshot is from the updated document processed in Studio and the second is of the only segment that appears in the Main TM even after I've tried updating it):

I don't really see the problem with this example.  You can see in the first image that "120" and "25" are recognised because they are underlined.  This means that even if you have the following none of them should be added to the TM at all:

QL (125 tablets / 23 days)

QL (236 tablets / 99 days)

QL (998 tablets / 436 days)

Studio only needs the one that is already in there:

QL (6 tablets / 21 days)

It will replace the recognised numbers based on what is in the source.

Melissa Wurst said:

I also created a Project TM and it does not seem to have this issue, as it contains all of the following TUs:

 

This I don't understand, but would really need to see the whole TU to comment on it, and it would be useful to understand how they got in the TM in the first place... the process.  Interactive translation, importing a TM etc.

Hi Paul,

The problem is that Studio is not replacing the recognized numbers based on what is in the source - I apologize if I did not make that clear from the beginning. It comes up as a 75% fuzzy match, like so:

The second set of screenshots is a TM that I created using the final Xliff for the last version of this document. I opened the Xliff, went to the Update Main TM batch task and instead of updating a TM I created a new one.

Melissa Wurst

I just aligned two files that were full of these texts.  The first point to note is that one one segment was added to my TM... as expected.  Interesting that the TU contains the first source TU and the last target TU, so the actual text in the TU is technically incorrect since the numbers don't match, but this doesn't matter as they are all tokens.

I then created a project wth the TM and the original source file... the entire file is translated despite there only being one TU in my TM:

This is the expected behaviour.  So if you are not seeing this then it's likely one of these things is not set for you:

• number recognition.  I have these settings on the TM I aligned to and use in my project:
  
• number auto-substitution in your Project Settings. I use these:
  

If this doesn't help I think the only way we'll get to the bottom of this mystery is to see your files from start to finish and try to reproduce exactl what you have done.

It was the Auto-substitution settings! Thank you so much - what a relief.

A follow-up issue: I need to use this TM, whose target language is ES (SP), for translation to ES (US). How can I do that so that the numbers aren't auto-localized for ES (SP)?

Melissa Wurst

Melissa Wurst said:

How can I do that so that the numbers aren't auto-localized for ES (SP)?

Export to TMX.

Create a new TM with the languages you want.

Import the TMX.

Will do - thank you!!