UI- und Übersetzungsgrundlage vor der Fachlichkeit

Bevor die erste echte Fachlichkeit in die Turnier-App einzieht, gibt es noch einen letzten Infrastruktur- und Setup-Schritt.

Wieder kein Spieler-CRUD.

Wieder keine Turnierliste.

Wieder keine Gruppeneinteilung.

Stattdessen:

Transloco
Tailwind
PrimeNG

Das klingt erstmal nach technischem Grundrauschen. Nach Projektsetup. Nach Dingen, die man auch später noch einbauen könnte.

Kann man.

Aber erfahrungsgemäß ist genau das der Punkt: Man kann es später einbauen, aber man bezahlt dann oft mit unnötiger Reibung.

Warum jetzt noch einmal Setup?

Nach den bisherigen Schritten steht die technische Basis.

Die Anwendung läuft. Die Container sind deployed. Das API Gateway ist abgesichert. Keycloak ist integriert. Die statischen Quality Gates der CI greifen.

Damit wäre es verlockend, jetzt direkt mit der Fachlichkeit zu starten.

Trotzdem lohnt es sich, vorher die UI- und Übersetzungsgrundlage festzulegen.

Denn sobald Features entstehen, entstehen auch Texte, Buttons, Tabellen, Formulare, Dialoge, Validierungsmeldungen und Layout-Entscheidungen.

Wenn diese Dinge ohne gemeinsame Grundlage wachsen, sieht man es später sofort:

• Texte sind hart codiert
• Komponenten sehen uneinheitlich aus
• Abstände entstehen zufällig
• Formulare werden jedes Mal neu zusammengebaut
• Übersetzung wird nachträglich in bestehende Templates operiert
• UI-Konventionen entstehen durch Zufall statt Entscheidung

Der Schritt ist also nicht glamourös. Aber er reduziert spätere Reibung.

Transloco, obwohl erstmal nur Deutsch?

Für die erste Version der Turnier-App reicht Deutsch völlig aus.

Der Verein ist lokal. Die Nutzer sind deutschsprachig. Die ersten Features werden für Trainer, Kampfrichter und eventuell Eltern gebaut. Es gibt also keinen akuten Produktdruck für Mehrsprachigkeit.

Trotzdem kommt Transloco früh ins Projekt.

Nicht, weil die App direkt international werden muss. Sondern weil Texte in einer Anwendung sehr schnell überall landen.

Ein Button hier. Eine Fehlermeldung dort. Eine Tabellenüberschrift. Ein leerer Zustand. Eine Dialogbeschreibung. Ein Toast. Ein Menütitel.

Wenn man diese Texte zunächst überall hart codiert, ist eine spätere Internationalisierung kein kleiner Umbau mehr. Dann muss man durch Templates, Komponenten, Tests und Validierungen gehen und nachträglich Struktur herstellen.

Das ist genau die Art Arbeit, die niemand gern macht.

Deshalb wird i18n vorbereitet, auch wenn zunächst nur eine Sprache existiert.

de

Das reicht.

Der Mehrwert liegt am Anfang nicht in der zweiten Sprache. Der Mehrwert liegt darin, dass Texte von Anfang an eine definierte Heimat haben.

i18n als Strukturentscheidung

Internationalisierung wird oft als Übersetzungsthema betrachtet.

Für mich ist es in diesem Schritt eher eine Strukturentscheidung.

Statt Texte direkt in Komponenten zu verteilen, bekommt die Anwendung eine klare Regel:

UI-Texte liegen in Übersetzungsdateien, nicht zufällig im Template.

Das ist besonders hilfreich, wenn später Coding-Agenten Features ergänzen.

Ein Agent, der ein Formular baut, soll nicht anfangen, Texte frei im HTML zu verteilen. Er soll bestehende i18n-Konventionen nutzen.

Damit ist Transloco nicht nur ein Werkzeug für Übersetzungen. Es ist auch eine Leitplanke gegen UI-Drift.

Ein späterer Prompt kann dann sagen:

Nutze die bestehende Transloco-Struktur.
Keine hart codierten UI-Texte.
Neue Keys sauber im passenden Namespace ergänzen.

Das ist deutlich besser als später aufzuräumen.

Tailwind als Layout-Werkzeug

Tailwind kommt als Layout- und Utility-Schicht dazu.

Nicht, weil jede Komponente ab jetzt aus zwanzig Utility-Klassen bestehen soll. Und auch nicht, weil CSS-Dateien verboten wären.

Tailwind ist hier vor allem praktisch für:

• Abstände
• Layouts
• Flex/Grid-Strukturen
• responsive Anpassungen
• einfache visuelle Komposition
• kleine UI-Korrekturen ohne neue Spezialklassen

Gerade in einer Anwendung, die am Turniertag wahrscheinlich auf Tablet oder Laptop funktionieren soll, ist schnelles und konsistentes Layout wichtig.

Turnier-Setup, Gruppeneinteilung, Ergebniserfassung und Tabellenansichten werden unterschiedliche Layout-Anforderungen haben. Tailwind hilft, diese Layouts pragmatisch aufzubauen, ohne für jede Kleinigkeit eine neue CSS-Klasse erfinden zu müssen.

Die Regel bleibt trotzdem:

Tailwind ist ein Werkzeug, kein Freifahrtschein für visuelles Chaos.

Auch hier braucht es Konventionen. Sonst wird aus Utility-first schnell Utility-Suppe.

PrimeNG als Komponentenbasis

Für die UI-Komponenten soll PrimeNG verwendet werden.

Das ist keine grundsätzliche Absage an Angular Material.

Im Gegenteil: Angular Material ist stark. Es ist sehr gut in Angular integriert, zuverlässig, gut dokumentiert und in vielen Projekten die naheliegendste Wahl. In professionellen Angular-Projekten ist Material oft die preiswertere Entscheidung, weil es sich zusammen mit Angular wie eine sehr natürliche Kombination verhält.

Wenn ein Team sowieso Angular nutzt, ist Material selten falsch.

Warum also PrimeNG?

Die ehrliche Antwort ist: Es ist teilweise Geschmackssache.

PrimeNG bietet eine breite Komponentenpalette und fühlt sich für viele Business-Oberflächen sehr vollständig an. Tabellen, Dialoge, Dropdowns, Buttons, Toasts, Panels und viele weitere Komponenten sind schnell verfügbar. Gerade für eine kleine Verwaltungs- und Turnier-App ist das attraktiv.

Dazu kommt ein persönlicher Grund: Beruflich arbeite ich fast ausschließlich mit Angular Material.

Das ist nicht schlimm. Aber gerade dieses Projekt ist auch ein Architektur-Labor. Es soll nicht nur ein Vereinsproblem lösen, sondern auch Raum für Erfahrungen schaffen.

Privat darf es deshalb bewusst einmal etwas anderes sein.

Kein UI-Framework-Krieg

Wichtig ist: Das ist kein Material-vs-PrimeNG-Bashing.

Beide Optionen wären vertretbar.

Angular Material wäre vermutlich die konservativere Wahl. PrimeNG ist hier die bewusst gewählte Alternative.

Die Entscheidung lautet also nicht:

Material ist schlecht.
PrimeNG ist richtig.

Sondern eher:

Material wäre absolut möglich.
PrimeNG passt für dieses Projekt gut genug
und bietet mir zusätzlich Erfahrungsgewinn.

Das ist eine legitime Architekturentscheidung.

Nicht jede technische Entscheidung muss aus zehn objektiven Kriterien mathematisch hergeleitet werden. Manchmal spielt auch Erfahrung, Motivation und Lernwert eine Rolle.

Solange die Entscheidung bewusst getroffen wird, ist das in Ordnung.

Was dieser Schritt leisten soll

Der Setup-Schritt hat ein klares Ziel:

Die Anwendung soll bereit sein, Fachlichkeit mit einer konsistenten UI- und Textgrundlage aufzunehmen.

Konkret bedeutet das:

• Transloco ist eingerichtet
• Deutsch ist als erste Sprache vorbereitet
• UI-Texte laufen über Translation Keys
• Tailwind ist eingebunden
• PrimeNG ist eingerichtet
• Theme und Styles sind grundsätzlich vorbereitet
• erste Shell-/Platzhalter-UI nutzt die neue Grundlage
• Builds und CI bleiben grün

Das ist wieder kein Feature im fachlichen Sinne.

Aber es verhindert, dass jedes spätere Feature seine eigenen UI-Grundlagen mitbringt.

Was bewusst nicht enthalten ist

Auch dieser Schritt bleibt begrenzt.

Nicht enthalten:

• keine fertige Design-Sprache für die komplette App
• keine ausgearbeitete Turniertag-UX
• keine Spielerverwaltung
• keine Gruppeneinteilung
• keine Ergebnisdialoge
• keine komplexen Tabellenansichten
• keine zweite Sprache
• keine vollständige Komponentenbibliothek

Das Ziel ist nicht, die finale Oberfläche zu bauen.

Das Ziel ist, die Werkzeuge sauber bereitzustellen.

Warum das für Coding-Agenten wichtig ist

Für KI-gestützte Entwicklung ist dieser Schritt besonders wertvoll.

Coding-Agenten orientieren sich stark an vorhandenen Mustern. Wenn noch keine UI-Konvention existiert, erzeugen sie eigene. Und wenn mehrere Prompts nacheinander ohne klare UI-Basis laufen, entstehen schnell unterschiedliche Stile.

Ein Feature nutzt hart codierte Texte.

Das nächste Feature legt eigene CSS-Klassen an.

Ein drittes Feature nutzt PrimeNG-Komponenten anders.

Ein viertes Feature baut eigene Buttons.

Das ist nicht böse. Es ist erwartbar.

Deshalb sollte die Grundlage früh sichtbar sein.

Der Agent braucht Beispiele und Grenzen:

Nutze PrimeNG für Standardkomponenten.
Nutze Tailwind für Layout.
Nutze Transloco für UI-Texte.
Keine hart codierten Labels.
Keine eigene Button-Komponente ohne Grund.

Je klarer diese Regeln im Projekt sichtbar sind, desto weniger muss der Agent raten.

Review-Fragen

Nach diesem Setup reicht es nicht, nur zu prüfen, ob die App noch startet.

Wichtige Review-Fragen sind:

• Ist Transloco sauber in der Standalone-App integriert?
• Gibt es eine klare Struktur für deutsche Übersetzungen?
• Sind neue UI-Texte bereits über Translation Keys angebunden?
• Ist Tailwind korrekt eingebunden?
• Beeinflusst Tailwind nicht ungewollt PrimeNG-Styling?
• Ist PrimeNG sauber konfiguriert?
• Gibt es ein erstes Theme oder eine nachvollziehbare Styling-Grundlage?
• Bleibt die App-Struktur weiterhin sauber?
• Wurden keine fachlichen Features nebenbei eingebaut?
• Bleiben Build, Format und CI grün?

Gerade der letzte Punkt ist wichtig: Setup-Schritte dürfen das Projekt nicht instabil machen. Sie sollen Reibung reduzieren, nicht neue erzeugen.

Der Stand vor der Fachlichkeit

Mit diesem Schritt ist die Infrastruktur-Reise vorerst abgeschlossen.

Die Turnier-App hat jetzt:

Frontend-App
API Gateway
Backend-Service
Datenbank
RabbitMQ
Keycloak-Login
JWT-Absicherung im API Gateway
stabile User-ID über sub
Audience-Prüfung
Transloco
Tailwind
PrimeNG
CI Quality Gates
Deployment

Das ist eine Menge Grundlage für ein Projekt, das fachlich noch nicht viel kann.

Aber genau das ist der Punkt.

Die Fachlichkeit soll nicht auf Sand gebaut werden. Sie soll auf einem Projekt entstehen, das bereits starten, bauen, deployen, authentifizieren und konsistent UI anzeigen kann.

Fazit

Dieser Schritt ist nicht spektakulär.

Aber er ist der letzte notwendige Setup-Schritt, bevor die eigentliche Turnier-Fachlichkeit sinnvoll beginnen kann.

Transloco sorgt dafür, dass UI-Texte von Anfang an strukturiert sind.

Tailwind gibt der App eine flexible Layout-Grundlage.

PrimeNG liefert eine breite Komponentenbasis für die kommenden Verwaltungs- und Turnieroberflächen.

Und die Entscheidung für PrimeNG ist bewusst pragmatisch: Angular Material wäre absolut möglich gewesen. Für dieses private Architektur-Labor darf es aber auch ein anderes Werkzeug sein — nicht aus Rebellion, sondern aus Lerninteresse und Geschmack.

Damit ist die Bühne vorbereitet.

Ab jetzt sollte es wirklich fachlich werden.