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

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

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

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

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

Hi Pascal,

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

Regards

Paul