Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feat]: Enable translation for service labels #536

Open
MoritzLost opened this issue Jun 22, 2023 · 6 comments
Open

[Feat]: Enable translation for service labels #536

MoritzLost opened this issue Jun 22, 2023 · 6 comments
Labels

Comments

@MoritzLost
Copy link
Contributor

Expected Behavior

As far as I can tell, the labels for individual services defined under categories.[category].services.[service].label are not translatable. The categories configuration is global, so we can only create one label there. The configuration reference doesn't contain anything regarding service labels, so I assume translating them isn't supported.

For some services this doesn't matter (Google Analytics, YouTube, etc. don't need to be translated). But for custom labels, like Another service mentioned in the example in the docs, those absolutely do need to be translatable. We might also need to add descriptions to individual services, which is possible since the label supports HTML. However, those descriptions then also need to be translated.

Current Behavior

Service labels are not translatable.

Steps to reproduce

Define services with custom labels for categories.

Proposed fix or additional info.

I suggest adding optional translation keys, either under language.translation.[language].services or under language.translation.[language].preferencesModal.sections.[0].services:

sections: [
    // …
    {
        title: 'Category',
        description: 'Category description',
        services: {
            my_custom_service: {
                label: 'My custom service',
            },
        },
    },
    // …
],

Version

3.0.0-rc.15

On which browser do you see the issue?

Firefox

@MoritzLost MoritzLost added the bug Something isn't working label Jun 22, 2023
@github-actions github-actions bot added the triage yet to be reviewed label Jun 22, 2023
@orestbida
Copy link
Owner

Sorry, this won't be worked on!

Services were not meant to be core function of the plugin and will likely never be (unlike other solutions such as Klaro). There is also no description or cookie management for a service; The idea was to take v2 and sprinkle something extra on top of it, although not too many new things as the plugin was already massive in size.

@orestbida orestbida closed this as not planned Won't fix, can't repro, duplicate, stale Jun 22, 2023
@orestbida orestbida removed the triage yet to be reviewed label Jun 22, 2023
@MoritzLost
Copy link
Contributor Author

@orestbida While I agree that the plugin should be kept small, I respectfully disagree that this is not important.

The description of your plugin explicitly mentions that it's supposed to be GDPR-compliant. Valid consent under GDPR requires that you inform the user which entities (services/providers) you're sharing data with. A cookie banner that only displays categories but doesn't show individual services won't be GDPR-compliant. In fact, you won't have valid consent even if the user accepts everything, because valid consent under GDPR requires informing the user of what data will be processed by whom.

So listing services is vital for GDPR-compliance, and those services can sometimes have names that need to differ between regions / languages.

I also don't think this would blow the plugin out of proportion – it's one additional property in the sections translations, and some checks in the output to check for label translations. The labels property could even be removed in favour of having those in the translations, this would be consistent with how all other texts are handled.

Would you be open to accepting a PR if I write this functionality myself?

@orestbida
Copy link
Owner

I agree that the user must clearly state what is being used and how it's being used. This however can be done without having to configure services, as all fields of the plugin accept html markup, making it relatively easy to add a list and much more.

I'm not aware of any law that requires individually togglable services though, in fact there are many GDPR compliant solutions that don't allow services at all.

With that said, I can keep this issue open at the very least, and if it gets enough attention/upvotes I will consider it!

@orestbida orestbida reopened this Jun 24, 2023
@github-actions github-actions bot added the triage yet to be reviewed label Jun 24, 2023
@orestbida orestbida added enhancement New feature or request low priority needs-votes and removed bug Something isn't working triage yet to be reviewed labels Jun 24, 2023
@orestbida orestbida changed the title [Bug]: Labels for services are not translatable [Feat]: Enable translation for service labels Jun 24, 2023
@MoritzLost
Copy link
Contributor Author

I'm not aware of any law that requires individually togglable services though

GDPR definitely requires informing the user of all the processing entities, and also being able to consent to each of them separately. Article 5 and 7 touch on this by mentioning that consent for data processing can't be lumped in with other things, but must be explicit for a specific purpose. Recital 32 also mentions it explicitly:

When the processing has multiple purposes, consent should be given for all of them.

It isn't explicitly spelled out in the GDPR, but any reliable, unbiased list of requirements for a GDPR-compliant consent tool will include the ability to consent to individual services. Take this checklist, for example:

  1. Nennung der Dienste, in die eingewilligt wird. Möglichkeit, pro Dienst einzuwilligen oder in Kategorien von Diensten→ Art. 12 DSGVO, Art. 7 Abs. 4 DSGVO

Translation:

Identification of the services to which consent is given. Possibility to consent per service or in categories of services.


in fact there are many GDPR compliant solutions that don't allow services at all.

Can you let me know what those are? 90% of services claiming to be GDPR-compliant are, in fact, not GDPR-compliant.


If I have the time, I'll see if I can raise a PR for this.

@orestbida
Copy link
Owner

It states that the user should have granular control and be able to accept/reject specific purposes (e.g. analytics, functionality, ads ...) if there are multiple purposes, but there is no requirement for "individually togglable services" within a category.

Some GDPR compliant solutions:

  • iubenda
  • cookiefirst
  • usercentrics
  • civic

Although many configure these solutions to not be fully GDPR compliant.

@MoritzLost
Copy link
Contributor Author

It states that the user should have granular control and be able to accept/reject specific purposes (e.g. analytics, functionality, ads ...) if there are multiple purposes, but there is no requirement for "individually togglable services" within a category.

The GDPR is so broad, and having a bunch of data processing services lumped together on one site is such a specific use-case, of course it won't be mentioned specifically. So it's a question of interpretation. I think the passages linked above clearly indicate that separate opt-in should be possible. Some data privacy protection officers that I've spoken to agree.

usercentrics

Is unfortunately not GDPR-compliant. See this article for details:
https://dr-dsgvo.de/usercentrics-praxistest-des-consent-tools-fuer-webseiten/

There's also an explicit case against Cookiebot (which has merged with UserCentrics):
https://dr-dsgvo.de/nutzung-von-cookiebot-auf-webseiten-ist-laut-verwaltungsgericht-wiesbaden-rechtswidrig/

Sorry, not sure if those resources are available in English.

Can't speak to the others, but most SaaS consent managers aren't GDPR-compliant, even though they claim to be.


Not sure where this debate is going – toggling individual services is already possible, after all. The only thing that's missing is the ability to translate the labels. This would bring this feature in line with the rest of the plugin's architecture (every part of the output is solely controlled by the language config), and, as far as I can tell, wouldn't be a huge addition in terms of file size or complexity. Or am I missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants