Giter VIP home page Giter VIP logo

Comments (10)

ptc avatar ptc commented on September 4, 2024

We'll check it. Meanwhile, can you try to put your labels directly into the oil configuration?

from oil.

ltparis2018 avatar ltparis2018 commented on September 4, 2024

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.

Ratcreamsoup avatar Ratcreamsoup commented on September 4, 2024

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.

ltparis2018 avatar ltparis2018 commented on September 4, 2024

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.

Ratcreamsoup avatar Ratcreamsoup commented on September 4, 2024

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.

ltparis2018 avatar ltparis2018 commented on September 4, 2024

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:

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:

  1. You generate a translated vendor list by merging global (english) vendor list and translated purpose texts by yourself.
  2. 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.

Ratcreamsoup avatar Ratcreamsoup commented on September 4, 2024

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:
image

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):
image

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.

ltparis2018 avatar ltparis2018 commented on September 4, 2024

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.

Waschnick avatar Waschnick commented on September 4, 2024

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.

Waschnick avatar Waschnick commented on September 4, 2024

Fixed with #228

from oil.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.