Hi Mariusz Lasota,

Can you please re-try using the Batch tasks> pre-translate function and while running the Settings in the pre-translate function, make sure the "Apply automated translation" is checked in the settings.

Let me know how it goes please!

Regards,

PS: Apologies, I was thinking of machine translation, but re-reading the post I realized it's not the case. Will check this and share my findings.

How it goes? The functionality is still broken but I managed to convert the numbers with a combination of regex filtering and bulk Find and Replace, so my immediate problem is resolved but it would have been nice to have such conversion done automatically like before.

Mariusz Lasota

I just realised you said Polish into English... I should have read that properly!  However, I recorded the test I just did with 2019 and 2021, perhaps it will help you with your task?  I'll do it again quickly later from Polish and share a screenshot of what happened.

I hope that's helpful and will inspire you to find a way forward now without having to revert to search & replace in the target afterwards.

Mariusz Lasota

In 2019 a pretranslation from a clean PL-EN Translation Memory returns this:

This was same as observed in the video.  I interactively translated the file and received matches properly (using the right language helped!!:

)

Pre-translating the full file gave me this:

So now 2019 gives me exactly the same result as 2021 except that pre-translation from a clean TM gets me an AT status on the first segment where it's a simple number:

16,45

In 2021 none of the three segments get an AT status.

So my conclusions are these:

1. with the right language pair and recognised placeables 2019 and 2021 behave almost exactly the same way
2. with non-recognised placeables 2021 allows you to achieve this good result by having improved language resource settings

I don't think there is a bug here, and if anything I think 2021 now behaves in a consistent way.  But there is an opportunity for enhancement if you believe that the interactive AT status should be achievable during pre-translation as well?  Certainly I think there is a strong argument for this given we know what the format should be, and we also receive them interactively.

I'll discuss this with the team and let you know what they think.  But in the meantime I do think you have a sensible workaround by just making sure the number formats you handle are properly configured and in your TM already.

Hi Paul,

Thank you very much for the time you took and your effort to do the experiment and thank you even more for proving my point at 5:50 of your video when you said with regard to 2021 "… and it's done nothing". Well, actually I can assure you that versions prior to 16.2.8.9097 would correctly convert the numbers and they would all pretty much look like segment 1 in your initial test with 2019, i.e. all the number-only segment would get converted and receive an unconfirmed blue AT status, which is just what I need.

When Studio was updated to 16.2.8.9097 some functionality was broken and this version no longer converts the numbers.

I would very much like this functionality to be restored.

I know about the inconsistent currency translation. Actually, when parts of a larger number are separated by a non-breaking space, the numbers get converted correctly.

Now, come to think of it, I have an idea, which could prove very powerful. Why not give a lot of power to the users by implementing some kind of regex based find and replace as part of Batch Tasks > Pre-translate Files? After all it all comes down to recognising a block of text and performing some operation on it. The the users could have the power to manipulate numbers, units, dates, acronyms, just about anything. This could take the form of a list of several find and replace expressions that could be executed in sequence for each segment. Just an idea!

For now I am going to downgrade to a previous version of 2021.

with kind regards,

Mariusz

What you ask for is a blind trust in a software. I am not so far and would not trust even the best software to do what a human can do. A software must assume, that the source is written correctly, and we both know how bad source in terms of numbers can be. Especially when the text has been created in Poland. You can have dot, space or non-breaking space (which would be the correct option) as thousand separator. So for numbers-only segments any kind of pretranslation may be a big risk. In my case customer uses 10.12.21 not as a date and such numerical values must remain untouched. However, logically Studio treats these as date and translates to 10.12.2021...

In order to avoid all the hassle I use what is available in Studio since the very beginning: a regex-capable display filter. To show only segments containing no translatable text I just enter ^[\d\W]*$ — then select all, copy source to target and that's it. Maybe you need to run a replacement for separators, but that goes quick. Replace all . by # then all , by . and finally all # by ,

Mariusz Lasota said:

When Studio was updated to 16.2.8.9097 some functionality was broken and this version no longer converts the numbers.

I would very much like this functionality to be restored.

Hi Mariusz Lasota

I would encourage you to investigate the contents of your TM.  I'd also ask you to take a clean TM and repeat this test in the downgraded version of 2021, when you downgrade, and see what you get.  You can see in the tests I did that 2019 certainly doesn't do this for anything other than the simplest of numbers.  I have no reason to think that earlier versions of 2021 did this any different.  So I would definitely be happy to see this if you are going to do it anyway.

Mariusz Lasota said:

Why not give a lot of power to the users by implementing some kind of regex based find and replace as part of Batch Tasks > Pre-translate Files?

I guess a post-processing on the target following pre-translation, or a pre-processing on the source before pre-translation, could be interesting.  I do think it could also be risky as you would be working blindly and may have to make changes afterwards to correctly handle your numbers.  With this in mind you can already solve this as Jerzy mentioned with various solutions available to handle search and replace across files, or complete projects.  So such a development would probably not get a high priority.  But it's certainly possible, and probably not complicated... just risky in practice.

Paul said:

I would encourage you to investigate the contents of your TM.  I'd also ask you to take a clean TM and repeat this test in the downgraded version of 2021, when you downgrade, and see what you get.

Hi Paul

I have already done that and all tests prove that 16.2.8.9097 carries a bug or functionality has been removed on purpose. I am aware of all the solutions you mentioned but they all required extra work and effort. It is not a pleasant feeling when something you rely on seizes to work or functionality is removed.

Jerzy Czopik said:

So for numbers-only segments any kind of pretranslation may be a big risk. In my case customer uses 10.12.21 not as a date and such numerical values must remain untouched. However, logically Studio treats these as date and translates to 10.12.2021...

Hi Jerzy, I know what customers do :-) Some still centre a title using a spacebar. We are an intelligent species and we can anticipate, counteract and prevent, which is not to say functionality should be removed because there is a rare case when it is not useful. I know I can convert numbers in a variety of ways but the best one I know is to rely on Pre-translate Files to do it for me and worry about exceptions later. This saves so much time  and it's a shame it does not work anymore and I don't know why. It seems nobody knows.

Hello Paul,

I would like to come back to this issue. I found this post looking for a solution for the same problem mentioned here, dates and number-only segments not being automatically translated and inserted during the pretranslation process (I am using Studio 2022). I proceeded to add a couple of segments in the TM with a similar date and number. I rerun the pretranslation and this time indeed those dates and number-only segments were pretranslated as 100% matches. However, there are two things that bother me.
First, they show as 100% matches, instead of AT, which I would have preferred. But most importantly, there is a problem, in my opinion, with how the results are displayed in the Translations Results window (see below). I can see it too if the screen shot you shared. 
My segment has been properly localized based on a TM similar match. However, the segment showing in the Translation Results window shows the source segment from the original match and the target segment of the localized new segment, so visually you have a 100% match where the SC and TG do not match. If I right-click on that TU showing in the Trans. Results window, and then Edit the translation unit, I obtain the original match where source and target do indeed match.  Is that normal behaviour? I find it very confusing getting 100% matches in the Translation Results window where the source and the target do not match. With text TUs containing texts differences are shown with tracked changes and you don´t get a 100% score unless it is truly a 100% match. Thanks. Beatriz
 

Beatriz de Vega 

Beatriz de Vega said:

First, they show as 100% matches, instead of AT, which I would have preferred.

The reason for this is that you have a number in your TM already.  So it is correctly shown as a 100% match.

Beatriz de Vega said:

so visually you have a 100% match where the SC and TG do not match

The way Trados Studio has always worked is that the TM does not require every number you translate to be stored in the TM.  It is enough for just one to be stored and then the number recognition feature will manage the rest.  You can test this using a completely new TM.  The first number you come across will probably show with an AT status and it will be stored in your TM.  Every number after that will not be stored (unless it's a completely different type of number) and every recognised number will be shown as a 100% match.

Beatriz de Vega said:

Is that normal behaviour?

Yes.

Thanks for your quick reply Paul. I understand how it works now and indeed I had tried with a completely new TM. My question regarding if it was normal behaviour, had to do more with the fact that in the Translation Results window you get a match with a 100% score but the source that is displayed does not match the target in the same displayed TU. Very confusing to me as a translator. Thanks.

Beatriz de Vega 

Beatriz de Vega said:

My question regarding if it was normal behaviour, had to do more with the fact that in the Translation Results window you get a match with a 100% score but the source that is displayed does not match the target in the same displayed TU.

Indeed it can be confusing.  Hopefully understanding how it's working explains... all numbers are the same as far as the TM is concerned.

Beatriz de Vega 

Beatriz de Vega said:

My question regarding if it was normal behaviour, had to do more with the fact that in the Translation Results window you get a match with a 100% score but the source that is displayed does not match the target in the same displayed TU.

Indeed it can be confusing.  Hopefully understanding how it's working explains... all numbers are the same as far as the TM is concerned.