Johannes Purer 

Are both your questions related to GroupShare TMs?  I ask because you posted into the Trados Studio forum and not the GroupShare one.  But just in case the first one isn't then you could use this app:

https://appstore.rws.com/Plugin/111

It says in the appstore it's for 2022 and not 2024, but it is a standalone app so in practice you can use it for any SDLTM.  You just won't see it in the Trados Studio appstore unless it has 2024 support added in the backend.  It doesn't use the APIs (if I recall correctly) so it's not sensitive to version.

On the GDPR question... my own opinion is that if it's a problem for you, then you as the host and admin of your GroupShare instance (so you are the data controller) need to make sure you update your TMs using non-publicly-identifiable usernames.  It's entirely a data issue.  I think there is an argument around legitimate business reasons for being able to identify who the translators were for quality assurance, attribution, collaboration, or audit trails for example, but that doesn't mean their real names need to be visible or that a client would be able to match the name with a person.

But I also think that anyone working in the industry who is concerned about sharing their usernames should ensure that they use one that doesn't give their identity away.  As the data controller you could always provide instructions to all your translators to ensure they understand their username will be stamped on their work and how they can go about setting that up in Trados Studio to help them remain anonymous.

Historically, if you need to clean up your existing TMs you could use a tool like the Data Protection Suite from the appstore that can also work with GropupShare TMs: https://appstore.rws.com/Plugin/39

But ultimately I think it's all down to you as the Data Controller... my opinion and not a legal one!

Johannes Purer 

Are both your questions related to GroupShare TMs?  I ask because you posted into the Trados Studio forum and not the GroupShare one.  But just in case the first one isn't then you could use this app:

https://appstore.rws.com/Plugin/111

It says in the appstore it's for 2022 and not 2024, but it is a standalone app so in practice you can use it for any SDLTM.  You just won't see it in the Trados Studio appstore unless it has 2024 support added in the backend.  It doesn't use the APIs (if I recall correctly) so it's not sensitive to version.

On the GDPR question... my own opinion is that if it's a problem for you, then you as the host and admin of your GroupShare instance (so you are the data controller) need to make sure you update your TMs using non-publicly-identifiable usernames.  It's entirely a data issue.  I think there is an argument around legitimate business reasons for being able to identify who the translators were for quality assurance, attribution, collaboration, or audit trails for example, but that doesn't mean their real names need to be visible or that a client would be able to match the name with a person.

But I also think that anyone working in the industry who is concerned about sharing their usernames should ensure that they use one that doesn't give their identity away.  As the data controller you could always provide instructions to all your translators to ensure they understand their username will be stamped on their work and how they can go about setting that up in Trados Studio to help them remain anonymous.

Historically, if you need to clean up your existing TMs you could use a tool like the Data Protection Suite from the appstore that can also work with GropupShare TMs: https://appstore.rws.com/Plugin/39

But ultimately I think it's all down to you as the Data Controller... my opinion and not a legal one!

Hi Paul,

thanks a lot for your quick reply.

Yes, both questions are related to GS TMs, but as the export is done in Trados Studio, I assumed there is no difference, if this is a GS or local TM.

If there is no other way, I can regularly export the GS TM, import it into a local TM and then use the tool you have suggested. Thanks.

Would it make sense to have this as a feature, to give the user options, what he/she wants to export?

Regarding the user name, you might be right. But how do you want to control as an LSP what user names your freelance translators are using?

This is far out of our control.

Freelancers have their own version of Trados, some of them for many years already, and when first opening the tool, they are asked to provide a user name. So I assume, most translators would use their own name, naturally. And that happens, when I look at the names in our TMs.

Is it a bit too easy for RWS as a tool provider to neglect this issue and give the responsibiltiy to the user? Does the freelance translator really think at that moment about where his/her data could end up?

There are so many options and functions in Studio, which many users probably never use or need, why not give the TM owner the possibility to decide which information fields are displayed and which not?

So more or less the same as with the export options.

Best regards,

Johannes

Johannes Purer said:

But how do you want to control as an LSP what user names your freelance translators are using?

This is far out of our control.

Johannes Purer 

Again... all my own opinion here as part of our discussion and not a legal position from RWS!

What a FL chooses to use is out of your control, but making sure they are aware of how their data could be used is not.

Johannes Purer said:

Is it a bit too easy for RWS as a tool provider to neglect this issue and give the responsibiltiy to the user?

Here's where I think some common sense needs to be applied.  In my opinion GDPR can be taken well out of context with people sometimes going way overboard in what they believe is required.  I think it's important to look at the intent of such a legislation and then look at your business practices.  For example:

1. As an LSP you do need to know who did what because you have legitimate business reasons for being able to identify who the translators were for quality assurance, attribution, collaboration, or audit trails for example.
2. As the GroupShare owner the data that it contains is entirely down to you:
   1. If you do not take the necessary precautions to ensure every person you work with is aware of how their data could be used then this is on you.
   2. If you do not go the extra, insignificant mile, to make sure the resources you are using don't understand how to anonymize what goes into their work I don't believe this is your problem.  But as it's an insignificant effort to do that with every job you send out why not do it?
3. As the Data Controller you do have tools available to you that can help you anonymise the metadata added to a TM or an SDLXLIFF
   1. in fact freelancers have this too

Johannes Purer said:

Is it a bit too easy for RWS as a tool provider to neglect this issue and give the responsibiltiy to the user?

As a tool provider we give users a blank slate.  In your case you have a solution that is on-premise and what you put into it is completely out of our control, and who you engage to contribute to the data you manage is also out of our control.  We can make sure the tools provide for a user to anonymise personal data used in the way we are discussing before work commences, and after, and we do that.  After that the responsibility has to rest with the user doesn't it?

Johannes Purer said:

There are so many options and functions in Studio, which many users probably never use or need, why not give the TM owner the possibility to decide which information fields are displayed and which not?

So more or less the same as with the export options.

I don't disagree with you here, and whilst we already provide functions and tools to help you manage your responsibility there are things that might be nice if you are exposing your users personal data to your clients.  I recommend you create an idea for that one.

Hi Paul,

thanks a lot for your detailed answer.

I agree with you, that it is up to us as the LSP to make sure we are compliant with GDPR. That's why I am asking.

But RWS as a tool provider should provide the functionality, so we can stay compliant with GDPR, when we work with the tool and provide access to linguists or clients.

It's by nature, that linguists and clients access the TM we provide to them, but the TMs contain sensitive information which we as an LSP cannot hide.

Besides that, I do not see the purpose of linguists or clients to know, who created, changed or last used a segment. This is information for the project manager.

I therefore will create an idea for development.

Best regards and thanks for your help,

Johannes