Die Rabattcodes haengen am Konto, nicht mehr am Abo

Filipe: "die partner codes sollen auch schon fuer die leute sichtbar sein
die angemeldet sind." Umgestellt, und auf Nachfrage dauerhaft: Rabattcodes
sind ab jetzt ein Konto-Vorteil, kein Abo-Vorteil.

WARUM DAS MEHR IST ALS EINE BEQUEMLICHKEIT

Der alte Riegel verlangte einen Abo-Status. Nachgesehen, statt vermutet:
Die Bezahlung auf abonnieren.html steht auf "Coming soon", bis Dogis
PayPal-Business-Zugang da ist (der Kommentar dort nennt es beim Namen).
Registrieren geht, bezahlen nicht. Der erste echte Partnercode lag damit
seit gestern hinter einer Tuer, die sich gar nicht oeffnen laesst -- er
waere fuer NIEMANDEN sichtbar gewesen ausser fuer Dogi und VanVan ueber
die Rollenvorschau.

Entschieden wird jetzt an "supporterToken" (beim Login gesetzt, beim
Logout entfernt, supporter.js). Der Abo-Stand wird als Sicherheitsnetz
weiter mitgelesen: Niemand soll Zugang verlieren, den er gestern hatte.

BEIDE STELLEN, NICHT EINE

Die Bedingung steht doppelt im Haus -- an der Kachel auf links.html und
an der Seite selbst. Nur eine davon umzustellen erzeugt einen Fehler, den
keine der beiden fuer sich zeigt: Man kaeme mit Konto auf die Seite und
saehe dort die Sperre. Beide sind umgestellt, tragen den Hinweis
aufeinander, und die Pruefung vergleicht sie in jedem Anmeldezustand
gegeneinander.

TEXTE, DIE SONST GELOGEN HAETTEN

"Nur fuer Supporter" auf einer Seite, die ein kostenloses Konto oeffnet,
schickt Leute zum Bezahlen fuer etwas, das sie umsonst bekommen. Kopf,
Vorspann, Kachelband, Beschreibung und Sperrtext sagen jetzt "Konto", in
allen fuenf Sprachen. Die Sperre bietet auf Filipes Wunsch beide Wege an:
den kostenlosen zuerst, das Abo daneben -- mit einer Zeile darunter, dass
es erst startet, wenn es offiziell live geht. Ohne die waere der zweite
Knopf eine Falle.

EIN FEHLER, DER SEIT DEM 03.08.2026 DRINSTAND

Die Pruefung meldete auf der FREIGESCHALTETEN Kachel weiter "Nur mit
Konto" statt "Freigeschaltet". Ursache: Das Skript setzte den Text
(`badge.textContent = ...`), aber applyTranslations() schreibt aus dem
data-i18n-Attribut zurueck -- und es laeuft danach noch einmal, weil
dogiSiteTexteLaden() die Texte aus der Verwaltung holt und dann neu
uebersetzt.

NACHGEMESSEN STATT HERGELEITET, und die erste Erklaerung war zu schnell:
Der Text war schon nach 50 ms falsch, also nicht "irgendwann spaeter
ueberschrieben". Der Grund ist, dass TEAM_API_BASIS auf den ECHTEN Worker
zeigt -- der Abruf gelingt selbst aus einer lokalen Testseite. Kontroll-
versuch mit blockiertem Abruf: derselbe alte Code, und das Band bleibt
korrekt. Ursache weg, Fehler weg.

Behoben, indem der SCHLUESSEL getauscht wird statt des Textes. Damit
schreibt jeder weitere Uebersetzungslauf von selbst das Richtige hin --
auch bei Sprachwechsel, wo die alte Fassung ebenfalls zurueckfiel.
Aufgefallen ist es nie, weil bis gestern niemand in den freigeschalteten
Zustand kommen konnte.

NEBENBEFUND, NICHT ANGEFASST: index.html hat dieselbe Bauart beim
Live-Status (#live-text mit data-i18n, Text per Skript gesetzt).
Gemessen ist es dort ein Wettlauf zweier Abrufe -- in meinem Lauf gewann
der Status um Haaresbreite, und ein Sprachwechsel repariert es dort
ohnehin (dogi-sprache-geaendert). Kleiner, aber echt. Auf Ansage.

pruef-rabattcodes EXIT=0 (63 Pruefungen, vorher 42). Neu darunter: drei
Anmeldezustaende statt zweier -- ausgeloggt, angemeldet ohne Abo,
angemeldet mit Abo --, jeder auf BEIDEN Seiten, dazu der Klick auf die
Kachel (fuehrt sie wirklich weiter?), die Beschriftung des Bands und als
Gegenprobe ein erzwungener Uebersetzungslauf, der den alten Fehler
zuverlaessig ausloest.

Co-Authored-By: Claude Opus 5 <[email protected]>

links.html

@@ -25,17 +25,34 @@
 <link rel="stylesheet" href="assets/css/theme-hasidog.css?v=20260828e" />
 <link rel="stylesheet" href="assets/css/theme-spicymedia.css?v=20260828e" />
 <style>
-  /* Rabattcodes: an das Supporter-Abo gekoppelt (Nutzer-Feedback
-     03.08.2026: "verbinde es mit dem Abo... wenn die Leute drauf drücken
-     wollen es nicht geht"). Eigener Knopf bleibt bestehen (führt weiter
-     eigenständig zu rabattcodes.html), wird aber nur für Supporter
-     tatsächlich anklickbar — sonst erscheint ein Hinweis mit Link zum Abo
-     statt der Navigation. Prüfung ist bewusst rein clientseitig (derselbe
-     zwischengespeicherte Login-Stand wie beim Nav-Abo-Knopf, siehe
-     renderAboButton() in main.js) — kein Aufruf-Zwang gegen den Worker bei
-     jedem Seitenaufruf, und da hier (noch) keine echten Rabattcodes
-     angezeigt werden, ist eine reine Client-Sperre für den jetzigen Stand
-     ausreichend statt eines vollen Server-Gates. */
+  /* Rabattcodes: an ein KONTO gekoppelt, seit 08.09.2026.
+
+     Ursprünglich (03.08.2026) hing die Kachel am Abo — Nutzer-Feedback
+     damals: "verbinde es mit dem Abo... wenn die Leute drauf drücken
+     wollen es nicht geht". Am 08.09.2026 hat Filipe das umgestellt: "die
+     partner codes sollen auch schon für die leute sichtbar sein die
+     angemeldet sind". Grund dahinter: Die Bezahlung ist noch nicht
+     freigeschaltet (abonnieren.html, "Coming soon…"), der Riegel war
+     also für niemanden zu überwinden.
+
+     Der Knopf bleibt bestehen und führt weiter eigenständig zu
+     rabattcodes.html, ist aber nur mit Konto wirklich anklickbar — sonst
+     erscheint der Hinweis mit beiden Wegen (anmelden/registrieren, und
+     daneben das Abo) statt der Navigation.
+
+     ⚠️ DIESELBE BEDINGUNG STEHT AUCH IN rabattcodes.html. Wer eine der
+     beiden ändert, muss die andere mitändern: Läuft nur diese hier auf,
+     kommt man mit Konto zwar auf die Seite, sieht dort aber die Sperre —
+     und andersherum blockiert die Kachel jemanden, der die Codes sehen
+     dürfte. pruef-rabattcodes.mjs vergleicht beide Seiten deshalb in
+     denselben drei Anmeldezuständen gegeneinander.
+
+     Prüfung ist bewusst rein clientseitig (derselbe zwischengespeicherte
+     Login-Stand wie beim Nav-Abo-Knopf, siehe renderAboButton() in
+     main.js) — kein Aufruf-Zwang gegen den Worker bei jedem Seitenaufruf.
+     Es geht darum, wem etwas angeboten wird, nicht darum, ein Geheimnis
+     zu hüten: Ein Rabattcode steht ohnehin in jedem geteilten
+     Bildschirmfoto. */
   .card-rabatt.gesperrt { cursor: not-allowed; }
   .card-rabatt.gesperrt:hover { transform: none; }
   .rabatt-gesperrt-hinweis {
@@ -45,6 +62,10 @@
   }
   .rabatt-gesperrt-hinweis[hidden] { display: none; }
   .rabatt-gesperrt-hinweis p { color: #ffe9a8; margin: 0; flex: 1 1 260px; font-size: .95rem; }
+  /* Zwei Wege nebeneinander (Wunsch 08.09.2026: "beides anbieten") — die
+     eigene Reihe hält sie beim Umbruch zusammen, statt den Abo-Knopf
+     allein in die nächste Zeile rutschen zu lassen. */
+  .rabatt-gesperrt-knoepfe { display: flex; gap: .6rem; flex-wrap: wrap; }
 </style>
 </head>
 <body class="mit-hintergrund" style="--page-bg:url('/assets/img/bg-links-seite.jpg');--page-bg-mobile:url('/assets/img/bg-links-seite-mobile.jpg');">
@@ -70,16 +91,19 @@
       <div style="max-width:1040px;margin:0 auto;">
         <a class="card card-brand card-feature card-feature-wide card-rabatt" href="rabattcodes.html" id="card-rabattcodes">
           <span class="card-feature-ring" aria-hidden="true"></span>
-          <span class="card-feature-badge" id="rabatt-badge" data-i18n="lk_rabatt_badge">🔒 Nur für Supporter</span>
+          <span class="card-feature-badge" id="rabatt-badge" data-i18n="lk_rabatt_badge">🔒 Nur mit Konto</span>
           <span class="icon-badge">🏷️</span>
           <span class="card-feature-text">
             <h3 data-i18n="lk_rabatt_h3">Rabattcodes</h3>
-            <p class="card-feature-desc" data-i18n="lk_rabatt_desc">Codes von Dogis Partnern — exklusiv für Dogfather-Supporter.</p>
+            <p class="card-feature-desc" data-i18n="lk_rabatt_desc">Codes von Dogis Partnern — für alle mit einem Konto.</p>
           </span>
         </a>
         <div class="rabatt-gesperrt-hinweis" id="rabatt-gesperrt-hinweis" hidden>
-          <p data-i18n="lk_rabatt_gesperrt_hinweis">🔒 Rabattcodes sind nur für Dogfather-Supporter zugänglich. Werde jetzt Supporter, um sie freizuschalten.</p>
-          <a class="btn btn-primary" href="abonnieren.html" data-i18n="lk_rabatt_btn_abo">Jetzt Supporter werden 👑</a>
+          <p data-i18n="lk_rabatt_gesperrt_hinweis">🔒 Die Rabattcodes gibt es für alle mit einem Konto. Melde dich an oder registriere dich kostenlos — dann sind sie da.</p>
+          <span class="rabatt-gesperrt-knoepfe">
+            <a class="btn btn-primary" href="abonnieren.html" data-i18n="lk_rabatt_btn_anmelden">Anmelden oder registrieren</a>
+            <a class="btn btn-outline" href="abonnieren.html" data-i18n="lk_rabatt_btn_abo">Supporter werden 👑</a>
+          </span>
         </div>
       </div>
     </div>
@@ -159,7 +183,7 @@
 </main>
 
 <div id="site-footer"></div>
-<script src="assets/js/i18n-links.js?v=20260828e"></script>
+<script src="assets/js/i18n-links.js?v=20260908a"></script>
 <script src="assets/js/main.js?v=20260828e"></script>
 <script>
 (function () {
@@ -172,12 +196,44 @@
     // Gleicher zwischengespeicherter Login-/Abo-Stand wie beim Nav-Abo-
     // Knopf (renderAboButton() in main.js) — kein API-Aufruf bei jedem
     // Seitenaufruf nötig.
+    //
+    // Seit 08.09.2026 entscheidet das KONTO ("supporterToken", beim Login
+    // gesetzt, beim Logout entfernt) statt des Abo-Status. Der Abo-Stand
+    // wird als Sicherheitsnetz weiter mitgelesen, damit niemand Zugang
+    // verliert, den er gestern hatte. Begründung im CSS-Kopf oben; DIESELBE
+    // Bedingung steht in rabattcodes.html und muss dort mitgeändert werden.
+    var angemeldet = !!localStorage.getItem("supporterToken");
     var status = localStorage.getItem("supporterSubStatus");
     var hatAbo = ["active", "pending", "suspended", "cancelled"].indexOf(status) !== -1;
+    var darfSehen = angemeldet || hatAbo;
 
-    if (hatAbo) {
+    if (darfSehen) {
       karte.classList.remove("gesperrt");
-      if (badge && window.dogiUebersetzen) badge.textContent = window.dogiUebersetzen("lk_rabatt_badge_frei");
+      /* DEN SCHLÜSSEL TAUSCHEN, NICHT DEN TEXT.
+
+         Vorher stand hier nur `badge.textContent = ...`. Das hielt genau
+         so lange, bis applyTranslations() das nächste Mal lief — und es
+         läuft danach noch mindestens einmal: dogiSiteTexteLaden() holt
+         die Texte aus der Verwaltung und übersetzt anschließend erneut
+         (main.js), ebenso jeder Sprachwechsel und jede nahtlose
+         Navigation. applyTranslations() liest den Schlüssel aus dem
+         data-i18n-Attribut — stand dort weiter "lk_rabatt_badge", war
+         das Schloss sofort wieder da.
+
+         Der Fehler war seit dem 03.08.2026 drin und ist nie aufgefallen,
+         weil bis zum 08.09.2026 niemand in den freigeschalteten Zustand
+         kommen KONNTE (das Abo ist noch nicht bezahlbar). Seit die
+         Kachel am Konto hängt, hätte jeder Angemeldete auf einer offenen
+         Kachel ein Schloss gesehen.
+
+         Mit dem getauschten Attribut ist jeder weitere Aufruf von
+         applyTranslations() harmlos — er schreibt jetzt selbst das
+         Richtige hin. Der textContent daneben ist nur dafür da, dass es
+         schon vor dem nächsten Aufruf stimmt. */
+      if (badge) {
+        badge.setAttribute("data-i18n", "lk_rabatt_badge_frei");
+        if (window.dogiUebersetzen) badge.textContent = window.dogiUebersetzen("lk_rabatt_badge_frei");
+      }
       return;
     }