I am having the same issue with the DeepL plugin. I get the same warning when I try to add it in the "Use..." function. I am using the SR1 version, just downloaded today.

Still having the same issue with the DeepL plugin after downloading version SR2...

Solved it. After re-downloading the plug-in, all I needed to do was go into Plug-Ins in the Add-Ins tab, and check the check box for DeepL. 

Brilliant! It solved the problem for me, too, for all the problematic plugins. But now RWS needs to figure out why this happens to some (fortunately, only a few) plugins. Normally, an installed plugin is also automatically activated. And the error message, obviously, gives no clue.

Thank you very much, Melanie! I shall add a note on this in my Studio manual.

Glad this helped!

Mats Linder 

Mats Linder said:

I shall add a note on this in my Studio manual.

I don't believe this was the fix.  Be careful what you write in your manual as it may mislead users.  The problem is entirely due to incompatible versions.

We will be releasing an update shortly that provides a more robust solution to ensure that if you have the wrong solution it will not show up in installed plugins at all, which was what was happening before.  This was never an issue in the past but the improvements made to the UI for 2022 SR2 highlighted this problem in a very unexpected manner.

Mats Linder 

Mats Linder said:

I shall add a note on this in my Studio manual.

I don't believe this was the fix.  Be careful what you write in your manual as it may mislead users.  The problem is entirely due to incompatible versions.

We will be releasing an update shortly that provides a more robust solution to ensure that if you have the wrong solution it will not show up in installed plugins at all, which was what was happening before.  This was never an issue in the past but the improvements made to the UI for 2022 SR2 highlighted this problem in a very unexpected manner.

I would write something like this: "If you have problem X, you might try to do Y." I don't see how this could hurt anything as long as Y is not a deep-going action (the action in this case could not hurt anything).

Anyway, this WAS the fix, at least for me and one other person. 

I don't understand about "incompatible versions" -- versions of what, incompatible with what? Once activated in the manner described by Melanie, the plugins worked and were obviously not incompatible. What really puzzles me, though, is that this problem seems to have occurred to so few users. And you said yourself that you could not reproduce it -- surely if it was a matter of incopatibility the problem would be easily reproduced.

What does having "the wrong solution" mean? How can I have "the wrong solution"? Of what?

Paul said:

This was never an issue in the past but the improvements made to the UI for 2022 SR2 highlighted this problem in a very unexpected manner.

Sorry -- this only makes me more confused. I understand nothing.

Anyway, it should be easy to explore the situation once SR2 is available.

Mats Linder 

Mats Linder said:

Anyway, it should be easy to explore the situation once SR2 is available.

It is available, and the CU9 fix resolving a problem to make this even more robust was released this week.

Mats Linder said:

What does having "the wrong solution" mean? How can I have "the wrong solution"? Of what?

Ticking the box in the Add-Ins tab is not the solution unless you had unticked it before.

Mats Linder said:

Once activated in the manner described by Melanie, the plugins worked and were obviously not incompatible.

This only worked after she downloaded the correct version and installed it.  

Mats Linder said:

Sorry -- this only makes me more confused. I understand nothing.

I'm afraid that if you start to document all of these things in your manual that are not really solutions because the real problem is not addressed that you are jus going to introduce confusion where it's not needed.  The current release with CU9 is more robust and will do a better job of handling plugins that should not be in there.  We'll never catch everything as it's always possible a plugin could have a problem that doesn't surface until you try to use it but at least we will not ensure old plugins don't show up as installed plugins (which was confusing), and we will better manage plugins that are not on the appstore but users got from their client or developed themselves.

Mats Linder said:

I don't understand about "incompatible versions" -- versions of what, incompatible with what?

Plugins should work using the supported public API for Trados Studio.  Each plugin has a setting in its manifest that specifies which version of Trados Studio it should be used for.  So for example when Trados Studio first came out every developer will have almost certainly used 17.0 as the minversion and 17.9 as the maxversion.  This means that the plugins will only install into any version of Trados Studio 2022 and nothing earlier. Hence a user of 2021 who double clicks the plugin will see the plugin manager shows the option to select 2021 is greyed out.

Unfortunately, in previous versions of Studio you could manually copy that plugin into the plugins folder and Studio would show it as installed even though it really wasn't because it would be incompatible with that version, which you would see if you double clicked it.

Then, we get SR1 for 2022.  This version has breaking changes in the API for some things and that means that some plugins will no longer work in SR1.  However, since nobody expected a breaking change (and there really should not be any in a CU or an SR), any plugins that had the maxversion of 17.9 will attempt to load them into SR1 as it would still be 17 point something.  The result being an error.

The resolution is twofold:

1. the developer of the plugin needs to update the maxversion to 17.09 for example so that it will not attempt to install into 2022 SR1 (this would be 17.1), and
2. the developer of the plugin needs to create a new version of the plugin that uses the updated APIs and set the manifest for it to minversion of 17.1 to make sure it will not install into the original 2022 release and only SR1

This time around we had this problem with SR1 and SR2 and even a few issues with CU's in-between.  This is difficult to resolve easily.  The sort of choices we have are these:

• set a minversion and maxversion that only allows installation into a specific Studio release.  But this would mean we would need new versions of every plugin whether they are affected or not for every CU and every SR released.
• set a minversion and maxversion that only allows installation up to the next SR and just release new plugins for every app with every SR.
• stick to a more rigorous development plan where we only release breaking changes in major releases (2019, 2021, 2022 for example) and also keep the APIs the same despite the CU and SR schedules.

Obviously the latter solution is the preferred one, but we are making so many huge changes in the product for the better, and because we have many different products all with their own development schedule and need to integrate with each other, that the development team have had to make changes in the updates within a major release.  I do believe we are getting to a point after many years of change where this won't be necessary much longer and we will be able to be more stable with no breaking changes to the public APIs between major releases.

Does this help you understand the problem a bit more?

Thank you, Paul, for your patience and detailed elucidations (once more). I now understand your previous statements much better; in fact, better than I ever had expected or even needed . I can assure you that I will not try to document any of these items in the manual; it would be going far too far (and I might still not even get it right...).

The only thing that I *will* mention (very briefly) is the possibility that if the user encounters a problem such as the one I described, it *might* because s/he might have unticked the corresponding box in the Add-ins tab, whether intentionally (and then had forgotten about it) or unintentionally. That's all. I can't see that a brief statement such as that could in any way cause confusion or misunderstanding. (It may of course be the case that only very few users ever have this problem, to for those few, that advice may be a big help, as it was to me.)