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.

Hi Mariusz Lasota,

Following -up on this one: with the changes in 2021 where we have significantly improved the auto-translatable aspects and recognition capabilities of a TM you need to have a similarly translated token in the TM before this will work.

So if you translate and confirm just one example of the number, or one example of the percentage, then the following you will receive 100% matches when pre-translating.

Does it help?

Hi Oana,

Unfortunately it does not help at all. I do not wish to confirm any number-only segments as this creates tons of junk in TM which causes lots of unacceptable problems later, especially with fuzzy matched numbers. I don't even want to entertain this idea. Actually, I make it a priority that absolutely no numbers (or single words) are stored in any TM and make the effort to periodically remove all this junk from TMs.

Could we just focus on broken functionality? Can you confirm that the latest version of SDL Studio does not convert numbers during Pre-translate File as the previous versions did?

Until this functionality is repaired, could someone direct me to a place where I can download the previous version before 16.2.8.9097 so that I can uninstall it and restore the version that worked? That would be very much appreciated.

As I said my go-to place for installation files has been wiped clean. Where can I get previous patches now?

Studio 2017 patches are still there, but 2019 and 2021 patches are all gone

Thank you!

Mariusz Lasota

Mariusz Lasota said:

I do not wish to confirm any number-only segments as this creates tons of junk in TM which causes lots of unacceptable problems later

It should not do.  You only need to have one entry in the TM and that one entry will be used to recognise how a number should be handled for that language pair. You only get a TM full of junk if the numbers are not recognised by the TM at all.  This isn't he case for the examples you have shown here.

The view internally is that right now there is nothing to repair.  In Trados Studio these settings on the specific language pair determine how placeables are handled.  This area has been hugely enhanced for many things in 2021 and it does ensure that we have more consistency around how results are handled and displayed.

We did discuss this with a developer yesterday, so if you still think you have a better case for the way numbers should be handled I think the best approach would be to create an idea in the ideas site and see if you can garnish some support:

https://community.rws.com/ideas/translation-productivity-ideas/i/trados-studio-ideas

Mariusz Lasota said:

As I said my go-to place for installation files has been wiped clean. Where can I get previous patches now?

You have a few options.  First you can use the locations in this KB:

https://gateway.sdl.com/apex/communityknowledge?articleName=000012378

Secondly, in your account you can also find the previous installers under "Archived Product Updates" in the "Downloads" section.  In here you will find, for example, SR1 CU8 for 2021 and SR2 CU7 for 2019.

I hope that helps.

Hi Paul,

Thank you for replying. I think there is misunderstanding. I am aware of the screen that you showed above and mine looks exactly like yours. I am very happy with the functionality Studio offers and how it handles placeables. So there is no need to post a new idea. I want the previously working functionality restored. The core of my complaint is that given no numbers are stored in a TM (actually, I don't think you even needed any TM connected!) Studio would normally convert numbers automatically during batch Pre-translate Files. As a result of this the automatically converted number-only segments would get an unconfirmed blue AT status like shown above (please see my original post at the top). Unfortunately, this functionality no longer works in 16.2.8.9097. After Pre-translate Files the number-only segments are left untouched and unconverted, status remains as "not translated."

This functionality is very important to me because I work on financial reports and technical manuals with lots of tables filled with numbers. This functionality ensures that Studio does the conversion at the project preparation stage mostly automatically taking away all the effort. Now I have to filter, use regex, merge files to work on them all at the same time and do all sorts of things to circumvent this problem.

This functionality clearly stopped working after the update. Can you confirm that this is a bug in 16.2.8.9097? I want to eliminate corrupt *.xml settings files as the culprit. 

Also thank you for indicating where I can get the archived versions of Studio.

Hi Paul,

Thank you for replying. I think there is misunderstanding. I am aware of the screen that you showed above and mine looks exactly like yours. I am very happy with the functionality Studio offers and how it handles placeables. So there is no need to post a new idea. I want the previously working functionality restored. The core of my complaint is that given no numbers are stored in a TM (actually, I don't think you even needed any TM connected!) Studio would normally convert numbers automatically during batch Pre-translate Files. As a result of this the automatically converted number-only segments would get an unconfirmed blue AT status like shown above (please see my original post at the top). Unfortunately, this functionality no longer works in 16.2.8.9097. After Pre-translate Files the number-only segments are left untouched and unconverted, status remains as "not translated."

This functionality is very important to me because I work on financial reports and technical manuals with lots of tables filled with numbers. This functionality ensures that Studio does the conversion at the project preparation stage mostly automatically taking away all the effort. Now I have to filter, use regex, merge files to work on them all at the same time and do all sorts of things to circumvent this problem.

This functionality clearly stopped working after the update. Can you confirm that this is a bug in 16.2.8.9097? I want to eliminate corrupt *.xml settings files as the culprit. 

Also thank you for indicating where I can get the archived versions of Studio.

Mariusz Lasota

Mariusz Lasota said:

This functionality clearly stopped working after the update. Can you confirm that this is a bug in 16.2.8.9097?

I can't confirm it's a bug.  When I spoke to the development team on this yesterday they explained that when Studio calls Core.TM search for pre-translate, it now passes SearchSettings.ComputeTranslationProposal = false, which prevents AT matches.  They then looked back at Core.TM code from Jan 2018, and having that flag true was already a requirement for AT matching, probably has been since forever.  So it's hard to prove but their guess is that earlier Studio versions passed that flag as true, and for some reason the latest doesn't.

But, I will pick this up again and raise a ticket for deeper investigation and if thought appropriate the dev teams will make whatever change is needed.

The important point for now however is that you can pre-translate against a TM if you have a single number formatted as needed in your TM.  You do not need to filter and use regex after the event.  If you are really worried you could even create a new TM just for the numbers and add this to your project settings.  Put it at the top of the list of TMs and then when you pre-translate you'll get what you need without adding any numbers to your main TM.  Although I'd very surprised if you didn't have any in there.  You must be very diligent in not confirming any segments that contain numbers at all.

Hi Paul,

Thank you for the clarification involving the SearchSettings.ComputeTranslationProposal flag. But since this has been the behaviour forever, how does this explain my case?

So, if you attempted to translate three plain text lines:

16,45

(-3,1415)

7 254 €

from, say, Polish into UK English, what would your Studio do during Pre-translate File?

Would it convert the lines to 16.45 and (-3.1415) and €7,254 or would these segments stay untouched? My studio would convert them before the update and will not convert them after the update. What is the cause?

Can you run this experiment on your PC?

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.