Comments (10)
We'll check it. Meanwhile, can you try to put your labels directly into the oil configuration?
from oil.
Unfortunately, I cannot reproduce this problem. Currently, there are different possibilities to configure texts for the Opt-In Layer and its CPC. I tested all of them.
The minimum configuration is as follows:
<script id="oil-configuration" type="application/configuration">
{
"advanced_settings": true
}
</script>
In this case no texts are configured and the default locale configuration of the layer is used. The layer correctly shows 'Purpose' for label_cpc_purpose_desc
.
Second option is configuration of locale directly within layer configuration in the web page. Here is my example (not all keys are configured to have a simple example here):
<script id="oil-configuration" type="application/configuration">
{
"advanced_settings": true,
"locale": {
"localeId": "enEN_00",
"version": 0,
"texts": {
"label_intro_heading": "Nutzung von Cookies und anderen Technologien",
"label_intro": "Die Website verwendet Cookies...",
"label_button_yes": "OK",
"label_button_back": "Zurück",
"label_button_advanced_settings": "Mehr Informationen",
"label_cpc_purpose_desc": "Verwendungszweck:"
}
}
}
</script>
The Opt-In Layer correctly shows "Verwendungszweck:" for label_cpc_purpose_desc
.
Third option is usage of a remotely accessable locale json as shown in this example:
<script id="oil-configuration" type="application/configuration">
{
"advanced_settings": true,
"locale_url": "http://<server>/<path to a remotely accessable locale.json>"
}
</script>
My remotely accessable locale.json contains the following definitions (again, not all keys are configured to have a simple example here):
{
"localeId": "deDE_01",
"version": 1,
"texts": {
"label_intro_heading": "Nutzung von Cookies und anderen Technologien",
"label_intro": "Die Website verwendet Cookies...",
"label_button_yes": "OK",
"label_button_back": "Zurück",
"label_button_advanced_settings": "Mehr Informationen",
"label_cpc_purpose_desc": "Verwendungszweck:"
}
}
The Opt-In Layer correctly shows "Verwendungszweck:" for label_cpc_purpose_desc
.
As already said I tested all three options and they worked for me. Could you post your configuration please? Then it may be easier to find the problem.
from oil.
Sorry for the long delay, I have been on vacation and without internet access. I have pinpointed the issue, I think. My intention was to have an external locale.json containing a default localized version of all texts that may be used for several sites and have these sites override specific texts (well, really just label_intro would be sufficient) with their own oil-configuration.
I had hoped that the texts-objects from locale.json and the on-page oil-configuration would be merged in a way that would give precendence to the local configuration while retaining all keys from the external json that are not defined in the local config.
As soon as I remove the locale-key from the onpage configuration, the texts set in locale_url are being shown as intended.
Here is my config which is causing the issue:
{
"publicPath": "//consent.some-domain.tld/1.2.2-SNAPSHOT/",
"poi_activate_poi": true,
"poi_hub_origin": "//consent.some-domain.tld",
"poi_hub_path": "/1.2.2-SNAPSHOT/hub.html",
"poi_subscriber_set_cookie": true,
"poi_group_name": "MyGroupName",
"advanced_settings": true,
"theme": "small light",
"cpc_type": "tabs",
"locale": {
"localeId": "deDE_01",
"version": 1,
"texts" :{
"label_intro": "My site-specific intro"
}
},
"locale_url": "//consent.some-domain.tld/locale/deDE_01_locale.json"
}
and consent.some-domain.tld/locale/deDE_01_locale.json is the same as here https://github.com/as-ideas/oil/blob/master/test/fixtures/config/deDE_01_locale.json.
As I said: if I remove locale from the configuration, all is well, although a site can no longer set their own text. Is there some way to achieve the desired behaviour or does each site need their full locale.json, even though there may just be minor differences (for example the company name in the intro)?
from oil.
Sorry for the delay. We were very busy the last month with another project.
The expected behaviour you described is exactly the behaviour that is implemented in the opt-in layer. I tried it with your configuration (except with another locale_url, publicPath and poi-hub configuration) - and it worked for me perfectly.
I saw the intro defined in page-specific configuration and all other texts retrieved from the url.
So this is a little bit mysterious. Are there any messages on the JS console?
from oil.
I just did another test case, this time using oil.1.2.5-RELEASE. If I have just "locale_url" pointing to my json file, all is well. If I add the "locale" property, the texts from the "locale_url" are being ignored and it falls back to the english default locale for anything not configured in the "locale" property in the advanced settings tab.
Console shows no error messages, it even says "Fetching data from url: //[myhost]/locale/deDE_01_locale.json", there's no CORS error or anything.
localeId and version properties are the same in both locale property and external json file, but I tried with different values in locale and locale_url, which didn't change the result.
So this works fine, though it will of course display the intro from the json file:
"locale_url": "//[myhost]/locale/deDE_01_locale.json",
while this here just displays the "My Custom Intro" and "Mehr Informationen" from the json-file, but english texts everywhere when I click on "Mehr Informationen":
"locale_url": "//[myhost]/locale/deDE_01_locale.json",
"locale": {
"localeId": "deDE_01",
"version": 1,
"texts" :{
"label_intro": "My Custom Intro"
}
},
For the time being, I'll work around the problem by creating a separate json file for each case, but it would be nice if I could just customize the intro if I actually need to customize it and still use everything else from the json file.
Just for to avoid confusion: This is the full config that is causing the problem:
<script id="oil-configuration" type="application/configuration">
{
"config_version" : 2018101101,
"publicPath": "//consent.some-domain.tld/",
"poi_activate_poi": true,
"poi_hub_origin": "//consent.some-domain.tld",
"poi_hub_path": "/hub.html",
"poi_subscriber_set_cookie": true,
"poi_group_name": "MyPOIGroup",
"advanced_settings": true,
"theme": "small light",
"cpc_type": "tabs",
"timeout": 60,
"locale_url": "//consent.some-domain.tld/locale/deDE_01_locale.json",
"locale": {
"localeId": "deDE_01",
"version": 1,
"texts" :{
"label_intro": "My Custom Intro"
}
},
"cookie_expires_in_days": 90
}
</script>
You should see the issue as soon as you click on the "Mehr Informationen" button. The inital opt in layer actually looks fine, it's just the advanced settings view that falls back to english locale.
from oil.
Ok, the hint to the CPC was helpful. I guess the problem is that your remotely retrieved locale.json
does not contain purpose texts in German.
The behaviour of OIL respecting the purpose texts is as follows:
- At first, purpose texts are searched in your locale definition.
- If no purpose texts can be found in locale definition, purpose texts are searched in global vendor list.
- The url the global vendor list is retrieved from can be configured in OIL configuration using parameter
iabVendorListUrl
(see documentation http://oil.axelspringer.com/docs/#functional-configuration-parameters). - If global vendor list url is not defined, the default is the IAB vendor list url https://vendorlist.consensu.org/vendorlist.json. This vendor list contains english purpose texts only.
The problem with the vendor list is that IAB provides an english version only. Translated purposes texts can be retrieved from special urls like https://vendorlist.consensu.org/purposes-<language>.json
(for example: https://vendorlist.consensu.org/purposes-de.json). But note: These special urls provide the purpose texts only, not the vendor list.
To get translated purpose texts, you have two options:
- You generate a translated vendor list by merging global (english) vendor list and translated purpose texts by yourself.
- You define own purpose texts in your language within the locale definition file using the
label_cpc_purpose
-labels. See OIL documentation (http://oil.axelspringer.com/docs/#language-label-configuration) for details.
from oil.
No, the remotely retrieved locale.json does contain the purpose texts in German. That's why they are displayed alright as long as I do not set an additional "locale"-property in the configuration - in that case, the purpose texts are being taken from that remote json that is set in the "locale_url" property alright:
After I add the additional "locale"-property in order to override just the one field from the remote json, the "more info" tab displays placeholder texts (label_cpc_purpose_desc) or english texts (everything else):
Note that some of the texts are still being correctly rendered from the external german locale file, namely label_cpc_heading and label_cpc_text. But label_cpc_purpose_desc and the label_cpc_purpose_0x_desc/label_cpc_purpose_0x_text (x=1-7) are actually present in deDE_01_locale.json, they are just being ignored.
What I want to achieve is simply overriding just the one field, label_intro, with some custom text, everything else that is not defined in the local configuration script block should be taken from the json file.
Let's say I have a couple of sites I want to use OIL on. One or two of those sites would have a slightly different intro text, depending on the company behind that site for example. Everything else is really generic and could be consolidated in the one remote deDE_01_locale.json. So for most sites, I would simply use this config:
{
"config_version" : 2018101101,
"publicPath": "//consent.some-domain.tld/",
"poi_activate_poi": true,
"poi_hub_origin": "//consent.some-domain.tld",
"poi_hub_path": "/hub.html",
"poi_subscriber_set_cookie": true,
"poi_group_name": "MyPOIGroup",
"advanced_settings": true,
"theme": "small light",
"cpc_type": "tabs",
"timeout": 60,
"locale_url": "//consent.some-domain.tld/locale/deDE_01_locale.json",
"cookie_expires_in_days": 90
}
</script>
Using this config I get all german texts from the deDE_01_locale.json anywhere in the OIL layer, even after clicking "Mehr Informationen".
Now on the one site with a different intro text, I would simply add the locale-property like so:
{
"config_version" : 2018101101,
"publicPath": "//consent.some-domain.tld/",
"poi_activate_poi": true,
"poi_hub_origin": "//consent.some-domain.tld",
"poi_hub_path": "/hub.html",
"poi_subscriber_set_cookie": true,
"poi_group_name": "MyPOIGroup",
"advanced_settings": true,
"theme": "small light",
"cpc_type": "tabs",
"timeout": 60,
"locale_url": "//consent.some-domain.tld/locale/deDE_01_locale.json",
"locale": {
"localeId": "deDE_01",
"version": 1,
"texts" :{
"label_intro": "My Custom Intro"
}
},
"cookie_expires_in_days": 90
}
</script>
I would expect everything to be rendered with the same strings as in the example before, except the label_intro. That is true for the initial screen - I've got "My Custom Intro" displayed from the local config, along with a "Mehr Informationen" from the json file. If I click on "Mehr Informationen", I get to the next view where I see missing localizations for most strings (see attached image above).
The only workaround I see at the moment is to avoid this approach with the "locale"-property altogether and just use an additional deDE_01_locale_custom.json file, which differs from deDE_01_locale.json in just this one text for label_intro.
I still think that this is a bug and not the intended behaviour.
from oil.
Thank you for your last detailed description. Now I could reproduce the problem that affects labels with prefix 'label_cpc_purpose' only.
It's a very strange behaviour. Currently, I haven't an idea about the reason yet. But now that we have understood the problem, we can analyze it.
from oil.
Found and fixed the issue:
Current procedure:
- OIL-Config with "texts" is loaded
- Missing labels are determined
** And missing labels are only the mandatory ones, i.e. all labels that do not start with label_cpc_purpose. Here is a filter implemented - If localeUrl is defined and there are missing labels, the missing information will be loaded from the url.
This means that the current implementation does only use the "missing labels".
Solution: Currently only missing labels are overwritten. This does not make sense. You can simply take anything that is not defined from the localeUrl.
from oil.
Fixed with #228
from oil.
Related Issues (20)
- It seems that the list of vendors is not IAB TCF compliant
- Integration IVW / SZMnG / script.ioam.de -> iom is not defined HOT 1
- [Q] how to `npm i` to actually get sources
- Hub errors saying it will use default Config in verboseMode
- Oil has a number of accessibility issues
- Users errors on e.event.source.postMessage(n,e.event.origin)
- Plans to support CCPA
- Opt-out and remove cookie? HOT 4
- Unable to npm install from version 1.3.5
- User required explicit opt-in in the manage option
- configuration ignored HOT 1
- Allow explicit loading to bundle oil.js with configuration.
- Install new SSL certificate (expired 13th February 2020)
- Add label "Publisher 3rd parties" to languages labels configuration
- Plans to support LGDP HOT 3
- Questions regarding the oiljs purposes configuration HOT 1
- Switch to TCF v2.0 since TCF v1.1 will soon no longer be supported HOT 3
- Certificate Error on documentation
- Reload page after accept consent
- Oil js not working. HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oil.