Beginnen Sie mit der Sprache des Besuchers, nicht nur mit der Standardsprache der Website
WordPress verfügt über einen Website-Lokal, aber mehrsprachige Websites benötigen oft Seiten-, Besucher- oder Plugin-Ebene-Sprachkontext. WPML macht die aktuelle Sprache über seine dokumentierten
wpml_current_language Haken, der es kompatiblen Codes ermöglicht, die Sprache zu lesen, die WPML für die aktuelle Anfrage ausgewählt hat.
ACookies nutzt dieses aktive Signal für die Website-Sprache, wenn es verfügbar ist, fällt dann auf die Browser-Sprache des Besuchers zurück und schließlich auf die konfigurierte Standardsprache. Dies hält den Banner näher an der Seitensprache, ohne jede Website auf eine einzige Erkennungsmethode festzulegen.
Übersetzen Sie die Entscheidung, nicht nur die Buttons
Ein mehrsprachiges Banner benötigt klare lokalisierte Formulierungen für den Zweck der Speicherung, die verfügbaren Aktionen, die Kategorien und den Richtlinienpfad. Wenn die Seite auf Schwedisch ist, aber das Präferenzpanel Analytics auf Englisch erklärt, hat der Besucher möglicherweise nicht genug Kontext, um eine informierte Entscheidung zu treffen.
Die Europäische Kommission beschreibt eine gültige Einwilligung als spezifisch, informiert, freiwillig und auf einer klaren bestätigenden Handlung beruhend. Für ein mehrsprachiges WordPress-Team wird dieser Standard die Übersetzungsqualität zu einer praktischen Einwilligungsfrage: Vage oder maschinenartige Texte können die Wahl auch dann schwer verständlich machen, wenn die Benutzeroberfläche die richtigen Buttons hat.
Verwenden Sie WPML-aware-Verhalten, wenn die Website bereits von WPML abhängt
Auf WPML-Websites sollte der Einwilligungs-Banner der Sprache folgen, die der Besucher tatsächlich sieht. Dies umfasst die erste Bannerschicht, das Anpassungspanel und die Links zu Cookie-Richtlinien-Seiten. Wenn eine Website pro Sprache separate Richtlinien-Seiten veröffentlicht, sollte der Banner die Besucher zur passenden Seite leiten, anstatt eine generische Standardseite.
ACookies umfasst für 25 Lokale Besucher-zugewandte Standards, bearbeitbare Sprach-Überschreibungen, WPML-bewusste Sprachabstimmung und Sprachkontext in Einwilligungsprotokollen. Diese Ansprüche entsprechen der lokalen Produktkonfiguration und dem Plugin-Sprachkatalog in diesem Repository.
Sprachen mit Rechts-nach-Links-Schriftart benötigen Layout-Unterstützung, nicht nur Textübersetzungen
Arabisch, Hebräisch und Urdu sind Rechts-nach-links-Lokalitäten im ACookies-Sprachkatalog. Der Banner und der Richtlinienblock benötigen die richtige Textrichtung, damit Satzfluss, Buttons, Kategorienlisten und Formularsteuerelemente natürlich wirken. Behandeln Sie dies als Layoutanforderung, nicht als nachträgliche Übersetzung.
Der Fallback-Pfad ist ebenfalls wichtig. Wenn eine angeforderte Sprache nicht aktiviert ist, verwenden Sie das konfigurierte Standardwert anstelle einer teilweisen oder mehrsprachigen Schnittstelle. Gemischte Inhalte sind schwerer zu überprüfen, schwerer zu unterstützen und leichter misszuverstehen.
Eine praktische Prüfliste für mehrsprachige Banner
- Öffnen Sie jede Sprachversion in einer neuen Browser-Sitzung und bestätigen Sie, dass die Banner-Sprache der Seite entspricht.
- Überprüfen Sie Akzeptanz, Ablehnung, Anpassung, Kategorienamen und Nachrichten für gespeicherte Entscheidungen in jeder aktivierten Sprache.
- Stellen Sie sicher, dass die Richtlinien-Links auf die richtige übersetzte oder absichtlich geteilte Richtlinien-Seite verweisen.
- Testen Sie rechts-nach-links-sprachen für Richtung, Fokusreihenfolge, Button-Layout und mobile Abstände.
- Lehnen Sie optionale Kategorien ab und überprüfen Sie, dass optionale Skripte gemäß dem konfigurierten Modus blockiert oder eingeschränkt bleiben.
- Überprüfen Sie Einwilligungsprotokolle, um sicherzustellen, dass Sprache, Richtlinienversion, Zeitstempel und Kategorien wie erwartet gespeichert werden.