Re: Consent Management - language handling should be based on locales, not on browser language

Consent Management - language handling should be based on locales, not on browser language

Status: Acknowledged
Submitted by Kronk ‎05-23-2018 05:41 AM - edited ‎05-23-2018 06:18 AM

Only using the browser language to determine which language version the prompt should show is not sufficient for clients that use one language in more than one country. For example we use German in Germany (locale de_DE) and Austria (locale de_AT) but visitors of both countries would see the same prompt with the same privacy policy URL (custom parameter) but they'd have to be different/country-specific. Otherwise we are going to send Austrians to the German privacy policy page and vice versa.

Status: Acknowledged

Hello @Kronk. Thank you for the GDPR enhancement idea. I have moved this to Acknowledged.

Comments
by kathleen_jo
on ‎05-24-2018 07:31 AM
Status changed to: Acknowledged

Hello @Kronk. Thank you for the GDPR enhancement idea. I have moved this to Acknowledged.

by Krasner
on ‎05-25-2018 01:08 PM

On a similar note, we would like to be able to use variables in the data layer, or by inspecting the URL, to set the user's preferred language. We have a language selector on our Web site, and we would prefer to display the prompt in the language the user has selected, rather than relaying on the browser locale.

by kathleen_jo
on ‎05-25-2018 02:34 PM

@Krasner That's a great idea. Thank you for sharing.

by Community Manager
on ‎06-22-2018 09:03 AM

Attached is a mockup of a possibility for what this could look like.

gdpr_add_language.png

by kathleen_jo
on ‎06-22-2018 10:26 AM
by lucie_corriveau
on ‎06-22-2018 10:41 AM

@kathleen_jo @DustinKirk That looks great! So under Rule, I could specify to use any variable in the data layer?

by Krasner
on ‎06-22-2018 11:08 AM

@kathleen_jo @DustinKirk This will work for us, thanks. However, for the Language option, I think you may need to include a boolean operatior dropdown as well, so that options such as "contains" or "equals" may be selected. This is because the html lang attribute can be not only a language code, but also could be a language+region code (locale). For example, our European spanish page has a lang value of "es-ES". That said, as long as there is also the option to use a rule, we could use that option instead.

by Community Manager
on ‎06-22-2018 12:49 PM

@lucie_corriveau @Krasner  Thanks for the feedback... sounds like simply making it a conditional would allow for greatest flexibility by allowing language or country to be targeted using any variable.

Language and country codes could even be its own pre-defined variables read from the DOM.  I've created a new product idea with that proposal... https://community.tealiumiq.com/t5/Product-Ideas/More-default-variables-for-server-domain-document-a...

-d-

by jason_paddock
on ‎06-22-2018 02:49 PM

@DustinKirk I like the idea of being able to chose/create a rule.  That should allow users the ability to customize how to know the specific language choice easily.  The next part that we should enable is the ability to provide their own names for the language on the left.  This way the user can define English (en-uk) and English (en-us).

Thanks!

by BenStephenson Contributor
on ‎06-25-2018 12:09 AM

@kathleen_jo That would work for the client/situation I was thinking about when I "liked" the suggestion.  They have load rules set up for locale/language combinations already (the language is in the URL and in the data layer) so this would work.