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.

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.

Thank you Oana,

MT is independent of number-only translation / conversion and does not rely of MT provider being "connected" therefore the "Apply automated translation" setting is irrelevant in this case (as far as I understand).

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.

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.