Hi, Does anyboday have some clues, please?

Hello Ulrike Michiels ,

What is the exact version of Studio and DeepL you have installed please- (the full version)

please also tell us the version of DeepL you have installed

Hi Steven, Do you habe any idea? Please excuse that I am insisting, but we are testing DeepL in our company, and we only have a limited time frame; we are stuck.

Hello Ulrike Michiels ,

Can you provide us please with the log file- you should find this here-

Hello Ulrike Michiels,

Thanks for the test files-

I have replied on email and are unable to reproduce.

If you could provide a telephone number that would be great as i'm not in the office next week.

Ulrike Michiels

I don't know if you had a call with Steve or not?  So a few things:

1. you should update Studio as this is not the latest version
2. you should provide more information about the type of file you are translating
3. you should tell us if the segments are pre-populated with copied source perhaps... or fuzzy matches
4. screenshots are always good
5. Any other information you can see that you have not told us

Hi Paul, It's great that you are there, because I was about to contact you, too, since Steven is on vacation.

1. We did - it did not help.

2. DOCX

3. No pre-translations are there

5. We think it has to do with our configuration: It is a terminal server environment (Citrix). The plugin can be selected in Studio under "All Language Pairs - TM...", but is not visible in the Plug-ins list or under "SDL Plugin Management". Have you tested the plugin in such an environment? How do we need to install it? As to SDL support, plugins need to be installed in the "ProgramData" folder when using a Citrix server; that's what we did.

Ulrike Michiels

Ulrike Michiels said:

It is a terminal server environment (Citrix).

It's very likely that this is the reason why the plugin fails.  Whilst you can use Studio in this environment it has not been built with this in mind.  The login credentials for the plugin use the Studio credentialstore which is in the roaming folder to ensure that they follow the user around.  If you use terminal server you most likely have users working with their own logins and as a result they won't see the credentials as they've been stored for a different user.

Is this how you're working? 

Yes, we use terminal server, and each user has an own login and profile which is used when logging in to another server. So do I understand correctly that the DeepL plugin has not been built for a terminal server szenario? But then why can it be installed for all users (ProgramData) on the PC (which in our company is a server) if then it doesn't have multi-user capability? What ideas do you have to still make it work?

Ulrike Michiels

Ulrike Michiels said:

So do I understand correctly that the DeepL plugin has not been built for a terminal server szenario?

No... as I tried to explain Studio has not been built for this model if you need to make use of the credentialstore.  The login details are held in here and this information is managed through the roaming folders in Studio... not Program Data.  This is intentional because the idea is credentials should follow the user.

Hi Paul, I summarize: SDL supports Citrix, and SDL supports plugins. We were told by SDL support that - using Citrix - plugins have to be installed in the ProgramData folder. But DeepL is not working like this. So where do we need to install the Plugin?

Ulrike Michiels

There is no point trying to twist words here.  I have explained this to you as clearly as I can.  If the plugins use the credentialsstore, which this plugin does, then you cannot use it through a terminal server unless all your users work with exactly the same login.

There is no magic solution other than to not use terminal server if you want to work with this particular plugin, or all use the same login credentials.  There are other plugins that have the same issue... it all depends on what they do.  Installing the plugin into programdata only allows all users to work with it without needing to install separately on each machine.  But if the plugin requires the use of some functions in Studio, like the credentialsstore, then it's not possible because Studio stores these in the Roaming folder and there is no way to change this.  It's also by design.

The only way this could work as you wish would be if DeepL licenced their product with a Network licence capability, but they don't as far as I'm aware.  It's a single user licence.

Ulrike Michiels

There is no point trying to twist words here.  I have explained this to you as clearly as I can.  If the plugins use the credentialsstore, which this plugin does, then you cannot use it through a terminal server unless all your users work with exactly the same login.

There is no magic solution other than to not use terminal server if you want to work with this particular plugin, or all use the same login credentials.  There are other plugins that have the same issue... it all depends on what they do.  Installing the plugin into programdata only allows all users to work with it without needing to install separately on each machine.  But if the plugin requires the use of some functions in Studio, like the credentialsstore, then it's not possible because Studio stores these in the Roaming folder and there is no way to change this.  It's also by design.

The only way this could work as you wish would be if DeepL licenced their product with a Network licence capability, but they don't as far as I'm aware.  It's a single user licence.