• State Suggested Answer
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 433 subscribers
  • Views 4255 views
  • Users 0 members are here
Options
Related

Trados propagating number combinations I did not enter.

Pascal Zotto

Hi,
I have a problem in Trados 2015. I have German to Luxembourgish (DE-DE > LB)  and soure string is an enumeration: 1.10
If I put 1.10 into target it gets then propagated to something I did not enter: 01:10 and I don't know how to get rid of that nasty habit if Trados. Why does it propagate something I did NOT enter?

I also see this quite often when using e.g. 1 TB with non-breaking space. It simply gets propagated to number(normal space)TB

Thanks for any help,
Pascal
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0
    Hi Pascal,

    Is this coming from your TM? Maybe check you don't have this entry for any number in your TM and if you do then delete it from your TM.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul
    Hi Paul,

    Just to make sure. Am not talking about pretranslation propagation but about on the fly translation and apparently there were no TM matches or fuzzies for these figures. But for the number(space)measure_unit it could well be there are hit in the TM.
    but unaware of existing TM Trados should NOT propagate possible hits from a TM for a translation I set in the actual document, it should propagate exactly what I set for that specific translation. If this is the standard behaviour of Trados then it should be fixed because every translation has its specific needs and translation versions. At least there should be a trigger/option to allow to choose which of these 2 settings should be propagated.
  • 0 in reply to Pascal Zotto
    Hi Pascal,

    I'm not familiar with your language pair, but something similar happens in EN-ES and it has to do with Autosubstitution, where Studio attempts to localize dates, times, measurements, etc. based on some set of rules which are are not available to the user. To disable this (which I agree makes no sense at all and is very inconvenient) you can set the TM to not recognize times by going to the TM's Fields and Settings and unchecking the Times checkbox in the Recognize section. You can also have a look at the Autosubstitution settings under Options/Project Settings - Language Pairs - Specific Language Pair - Autosubstitution.
  • 0 in reply to Nora Díaz
    Hi Nora,

    I just tried to deactivate that option but now it seems not to propagate such enumerations (1.1 to 3.14) anymore at all.
  • 0 in reply to Pascal Zotto

    Hi Pascal,

    I'm not sure we're talking about the same thing, but I'll try to explain what I see and how I fix it. For my language pair, this happens when I have a number such as "1:00", so if I have the default settings (TM to recognize Times and Autosubstitution checked for Times), this is what happens:

    Notice the blue underline indicating the recognized token (Time) and notice how segments 2-4, all propagated from segment 1, have a different format, with an extra zero added at the beginning and "a. m." added at the end. That comes from Studio's Autosubstitution settings, so it's a combination of two things: times being recognized as a token, and the token being autosubstituted according to Studio's own rules. 

    If I go the the TM settings and uncheck the Times box so times won't be recognized as a token, I now get this, where you can see that the underlined tokens are now the numbers on either side of the colon, and now Studio propagates the numbers the way I need them:

    Of note: for this change to "stick" and work properly, I find that I need to close the file and then reopen it.

    Maybe it would be helpful if you could share a screenshot of what you're seeing so we can understand what tokens are being recognized and propagated.

    Best,

    Nora
  • 0 in reply to Nora Díaz

    One more thing to look at is the formats available under the Short time Autosubstitution options for your language pair. My language pair does have an option for the short time that is H:mm, it's just not the default. If you find the right format in there, then just selecting it should solve the issue and you shouldn't have to change the TM recognition settings. : )

    Project Settings - Language Pairs - Specific Language Pair - Translation Memory and Automated Translation - Auto-substitution - Dates and Times - Short time
  • 0 in reply to Nora Díaz

    Yes, we are talking about the same options to (de)activate but I'm not talking about 1:11 to 1:11 propagation but that the system converts enumeration 1.11 to 1:11 although I translated 1.10 to 1.10 beforehand.

    And yes, I did also find out that without closing the file it would not "recognize" the option change. ;)

    See here what I mean. I confirm 3.10 and it then wants to propagate all hits with x:xx ?! As you can see we have 1.10 which is not a time code, at least non known to me for German (source) or Luxembourgish (target) as time is always written with colon.

    regards,

    Pascal
  • 0 in reply to Pascal Zotto

    Hi Pascal,

    Wow... I'm not sure what to make of this.  I tested this with a brand new TM, de(DE) - lb(LU), and was very surprised at the results.  I think I can sort of see why it's behaving this way, but also see why it's less than desirable!

    First of all with the default settings if I confirm segment #1 I get this:

    This has some interesting results:

    1. It definitely treats 3.10 as a time and I think this is because of the dot instead of the comma in the German source
    2. When it hits segment #4 it misses it because 1.60 as a time is really 2.0 which makes sense and was cleverer than I expected!  So it would handle this a number in the way you wanted.
    3. Segment #6 is odd because it seems to get confused when I go past 24, in fact only up to 24.12 because it corrects itself after that!

    So, some things are explainable I think, and some not... and a little buggy in a very unusual case I think.  Now, if I change the Time/Date settings as Nora suggested then I can fix all of this for these cases for interactive translation:

    Change the short time to H.mm and then all these numbers are recognised as you would like, even if it is for the wrong reason, but unfortunately only in interactive translation.  They still seem to pre-translate with the colon as before.

    I think this is buggy and we need to look at it.  Your best bet is probably to allow Studio to do what it wants so you get the correct number transposition at least and then use a search and replace (regex) to correct them.  Of course if you only have number only segments as in my example the best solution is to handle them before you even start translating.  So filter on these segments only, copy source to target, then change status to translated and lock them.  Now they can't be changed and will all be as required.

    I hope this helps, and in the meantime I'll report this issue just to make sure we are aware of this in development.

    Thank you for reporting it.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul
    Hi Paul,

    I did not have time to test it yet but just a small advance answer in order for SDL to get the format right. It seems SDL sets H.mm as German (DE-DE) time format but that time format does not exist in official texts and is also not allowed according to the DIN 5008 norm for time formats and HH:mm for times with one digit hours (e.g. 9:00) setting the hour to 2 digits should be avoided (e.g. wrong: 09:00 > correct 9:00). Please also see de.wikipedia.org/.../Uhrzeit

    Here you can see that the only German variant where H.mm is allowed is Swiss German (DE-CH), so Trados should be set to not have H.mm (as it can be seen in the screenshots we posted) as source format for DE-DE, DE-AT and DE-LB but H:mm.

    Regards,
    Pascal
  • 0 in reply to Pascal Zotto

    Hi Pascal,

    Studio uses the formats in your operatng system.  For de-DE that time format is allowed:

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul
    well it's not the first time MS would be wrong with such settings. Will get into touch with them to check that as I'm very well placed for such queries with MS. ;)
Reply Children
No Data