Oveleon Cookiebar – Mehrsprachig

Ich habe nun auf einer zweisprachigen Seite zwei Cookiebars eingerichtet und diese den jeweiligen Startpunkten zugeordnet. Speichere ich nun beim Aufruf der Website Einstellungen in einer Sprache und wechsele zur anderen Sprache, erscheint die Cookiebar erneut, die Einstellungen werden nicht übernommen und müssen erneut vorgenommen werden. Dasselbe gilt für die Änderung der Einstellungen oder die komplette deaktivierung aller Schalter in der Cookiebar: Sie gelten immer nur für eine Sprache. Das bedeutet, dass die Einstellungen für die Sprachen inkonsistent sind.

Ich gehe davon aus, dass es daran liegt, dass die Cookies für die Sprachen mehrfach angelegt wurden und jeweils eigene IDs haben.

Ist das so vorgesehen oder kann ich die Mehrsprachigkeit anders/besser lösen? Im Moment würde mir aber nur einfallen, die Texte in den Cookiebar-Einstellungen in {{ iflng::XX }}-Inserttags einzugeben, was aber unübersichtlich ist.

Danke und viele Grüße
Timo

Zitat:

---

Zitat von intradesign

Ich gehe davon aus, dass es daran liegt, dass die Cookies für die Sprachen mehrfach angelegt wurden und jeweils eigene IDs haben.

---

Nicht direkt die IDs der Cookies aber die der Konfiguration. Solltest du die selbe Konfiguration verwenden, sollte die Cookiebar nicht erneut angezeigt werden. (Sofern es sich um die selbe Domain handelt)

Zitat:

---

Zitat von intradesign

Ist das so vorgesehen oder kann ich die Mehrsprachigkeit anders/besser lösen? Im Moment würde mir aber nur einfallen, die Texte in den Cookiebar-Einstellungen in {{ iflng::XX }}-Inserttags einzugeben, was aber unübersichtlich ist.

---

Eine Alternative wäre die Verwendung von dieser Erweiterung:
https://extensions.contao.org/?q=con...nstants-bundle

Das habe ich selber allerdings noch nicht getestet.

Aber wie macht ihr das selbst bei mehrsprachigen Websites? Eine Konfiguration und Inhalte per Inserttags? Oder eine Konfiguration je Sprache?

Die Constants-Erweiterung von Trilobit ist wahrscheinlich sowas wie die alte Inserttags-Erweiterung? Da könnte ich vielleicht auch Nodes nehmen?
Aber wenn ich die Inhalte noch an anderen Stellen verwalten muss, wird es ja gleich wieder unübersichtlich. Das schöne an eurer Erweiterung ist ja, dass alles so übersichtlich ist. Sonst kann ich sie auch gleich wieder alles in eine Config-Datei schreiben und ein anderes Consent-Tool nehemen, was ich aber auch doof finde...

Zitat:

---

Zitat von intradesign

Aber wie macht ihr das selbst bei mehrsprachigen Websites? Eine Konfiguration und Inhalte per Inserttags? Oder eine Konfiguration je Sprache?

---

Das kommt ganz auf die Inhalte / Services an, welche in den jeweiligen Startpunkten der Kunden eingerichtet sind. Wenn unterschiedliche Services benötigt werden, müssen entsprechend zwei eigene Konfigurationen her.

Zitat:

---

Zitat von intradesign

Die Constants-Erweiterung von Trilobit ist wahrscheinlich sowas wie die alte Inserttags-Erweiterung?

---

Denke schon, ich kenne die alte Erweiterung leider nicht.

Zitat:

---

Zitat von intradesign

Aber wenn ich die Inhalte noch an anderen Stellen verwalten muss, wird es ja gleich wieder unübersichtlich. Das schöne an eurer Erweiterung ist ja, dass alles so übersichtlich ist. Sonst kann ich sie auch gleich wieder alles in eine Config-Datei schreiben und ein anderes Consent-Tool nehemen, was ich aber auch doof finde...

---

Also mal davon abgesehen, denke ich, ist der normale use-case sowieso nicht, dass ein Besucher erstmal die DE-Seite konsumiert und anschließend auf die EN wechselt. Daher sollte es m.E. auch kein Problem sein, wenn zwei Konfigurationen eingerichtet werden, in der du deine Sprachen entsprechend pflegst. Aber ja, hier müsstest du dich für eine Variante entscheiden.

Anders gefragt, wie sähe dein Verbesserungsvorschlag aus? :)

Man könnte in der Extension DC_Multlingual nutzen. Ich persönlich finde es davon abgesehen aber auch ok, wenn man den Consent nach dem Wechsel der Sprache neu setzen muss. (Blöd ist nur, dass man dann auch mit mehreren Consent IDs für die Custom Scripts arbeiten muss.)

Zitat:

---

Zitat von Spooky

Blöd ist nur, dass man dann auch mit mehreren Consent IDs für die Custom Scripts arbeiten muss.

---

Ich meine, es müsste auch funktionieren, wenn hier die Cookie-Namen (Token) angegeben werden, bspw.:

Code:

---

document.addEventListener("DOMContentLoaded", function() {
    cookiebar.addModule('_ga', myCallbackMethodWithInitialization);
});

---

Aber eine ID hat ja mehrere Cookie Namen (Komma getrennt)? Und was macht man, wenn man einen externen Service hat, der keine Cookies setzt? ;) Da gebe ich ja nichts als Cookie-Token an.

Zitat:

---

Zitat von Spooky

Aber eine ID hat ja mehrere Cookie Namen (Komma getrennt)?

---

Es dürfte nur einer der Cookie-Namen angegeben werden. Die Funktionalität kommt dann aus der issetCookie-Methode und prüft, ob zu diesem Token ein Cookie-Typ ermittelt werden kann.

Zitat:

---

Zitat von Spooky

Und was macht man, wenn man einen externen Service hat, der keine Cookies setzt? ;) Da gebe ich ja nichts als Cookie-Token an.

---

Dann guckt man in die Röhre :D
Ich schätze diesen use-case könnte man ggf. über einen Alias lösen, welcher zukünftig ebenfalls angegeben werden kann.

Ja, habe ich mir auch schon überlegt, aber muss dann halt ein non-unique Alias sein. Oder er muss zumindest innerhalb einer Cookiebar Konfiguration unique sein.