In App Store Connect steht ein Pflichtfeld für die Datenschutz-URL

Pro App. Und wer seine App nicht nur in Deutschland anbietet, braucht die Seite dahinter auch in den Sprachen, in denen sie verkauft wird.

Bei DevPreview ging das noch von Hand: eine Seite, deutsche und englische Fassung untereinander, Link in App Store Connect eintragen, erledigt. Dann stand die zweite App vor der Tür, und aus der einen Seite wurde eine Multiplikationstabelle – Apps mal Sprachen mal Dokumente. In einem Astro-Projekt ist jede Zelle dieser Tabelle eine eigene Datei im Repository. Wenn ich eine Speicherdauer ändere, ziehe ich sie überall nach. Beim dritten Mal vergesse ich eine, und dann steht in der englischen Fassung eine Frist, die in der deutschen längst anders lautet.

Odoo hängt Übersetzungen an denselben Datensatz wie das Original. Ich pflege einen Text, wechsle die Sprache und übersetze die Absätze, die sich geändert haben. Kein zweiter Verzeichnisbaum, keine Datei, die aus dem Tritt gerät.

Der Nebeneffekt, den ich unterschätzt hatte

Ein Tippfehler auf der Startseite bedeutete bisher: Editor auf, Datei suchen, ändern, committen, pushen, Build abwarten, deployen. Für ein Wort.

Astro trifft daran keine Schuld, der Generator arbeitet sauber. Aber jede Änderung durchläuft dieselbe Kette, egal ob ich einen Buchstaben tausche oder eine ganze Seite baue. Jetzt logge ich mich ein, klicke in den Text, speichere, fertig.

Längere Beiträge schreibe ich weiterhin in Markdown – in einem WYSIWYG-Editor tippe ich freiwillig keine 1.200 Wörter. Den Weg in die Datenbank übernimmt mein Modul eq_website_markdown_import: Titel, Lead, Tags, Publikationsdatum und die SEO-Felder stehen als YAML-Header in der Datei, Bilder liegen als ZIP daneben, das Modul verdrahtet beides zu einem fertigen Beitrag.

Fehlt der Titel, rächt sich das sofort: Ohne title: im Frontmatter zieht der Importer den Dateinamen als Beitragstitel – und dann steht über dem Artikel ein Konstrukt aus Datum und Bindestrichen. Zwei Minuten gespart, zehn Minuten nachgearbeitet.

Die Spielereien sind mitgekommen

Auf der Seite liegen ein paar kleine JavaScript-Spiele und Gimmicks, die ich über die Zeit gebaut habe. Genau die hielt ich für den kritischen Teil der Migration, weil ich damit gerechnet hatte, dass Odoo mir beim Einbinden eigener Skripte in die Quere kommt.

Hat es nicht. Die Spiele hängen an keinem Framework, sind reines Vanilla-JS und damit eine Frage von Dateien im Asset-Verzeichnis plus einer Seite mit einem HTML-Block. Aufwand: ein Nachmittag, und der ging überwiegend für das Aufräumen von Pfaden drauf, die ich vor Jahren hart verdrahtet hatte.

Die Reichweitenmessung bleibt im Haus

Kein Google Analytics, kein Dienst bei einem Dritten. Die Messung läuft über ein eigenes Odoo-Modul auf meinem eigenen Server bei Hetzner, und die Aufbewahrungsfristen habe ich gesetzt, statt sie von einer Voreinstellung übernehmen zu lassen:

• Server-Logs: 7 Tage
• Reichweitenmessung: 12 Monate
• Kontaktformular-Anfragen: 24 Monate

Seit dem Umzug liegen diese Daten und die Inhalte, über die sie erhoben werden, in derselben Datenbank. Eine Auskunft nach Art. 15 DSGVO beantworte ich über einen Kontakt-Datensatz statt über zwei Systeme und ein gutes Gedächtnis.

Was ich mir eingehandelt habe

Eine statisch ausgelieferte HTML-Datei ist schneller als eine Seite, hinter der ein Python-Prozess und eine Datenbankabfrage stehen. Der erste Seitenaufbau ist seit heute langsamer, und daran ändert kein Feintuning etwas Grundsätzliches.

Was hilft, ist unspektakulär: Asset-Bundles aktivieren, Caching-Header sauber setzen, Bilder in der Größe ausliefern, in der sie angezeigt werden, und keine Snippets stapeln, die niemand braucht. Damit landet die Seite in einem Bereich, der für eine Entwickler-Visitenkarte mit zwei Apps im App Store vollkommen ausreicht. Wer eine Nachrichtenseite mit sechsstelligen Zugriffszahlen betreibt, trifft diese Entscheidung anders.

Und wer eine reine Content-Seite pflegt, ohne Formulare, ohne Kundendaten, ohne rechtlich verbindliche Dokumente in fünf Sprachen, hat mit Astro das bessere Werkzeug in der Hand. Für mich hat sich der Wechsel gelohnt, weil ich Odoo ohnehin täglich anfasse und mir fehlende Module selbst schreibe. Ohne diese Voraussetzung wäre der Umzug kein Gewinn gewesen, sondern ein zweites Projekt neben den Apps.