Beginne mit teuren Fehlern
Ein Linter kann Tausende Sätze in Sekunden prüfen, deshalb ist die Versuchung groß, jede Stilpräferenz zu kodieren. Beginne stattdessen mit falschen Produktnamen, inkonsistenter Terminologie, riskanten Formulierungen, unklaren Warnungen und wiederkehrenden Formatfehlern.
Wenn der erste Lauf Hunderte unwichtige Hinweise produziert, lernt das Team, das Tool zu ignorieren.
Behandle Regeln wie Code
Speichere Vale-Konfiguration und Vokabulare im Repository, reviewe Änderungen und benenne Regeln nach ihrer Absicht. ApprovedProductNames ist verständlicher als RegexRule17.
Kleine Fixtures mit positiven und negativen Beispielen helfen, Regressionen zu verhindern.
Trenne Errors und Hinweise
Blockiere einen Build nur bei Problemen, die das Team wirklich als verpflichtend definiert hat. Verwende Warnings, wenn redaktionelles Urteil nötig ist. So bleibt CI vorhersehbar.
Pflege Terminologie zentral
Approved Names, Schreibweisen und Ersetzungen sollten an einer Stelle gepflegt werden. Produktspezifische Ausnahmen gehören explizit in die Regeln, nicht in globale Deaktivierungen.
False Positives sind ebenfalls Signale: Manchmal ist die Regel falsch, manchmal erzwingt das Content Model inkonsistente Formulierungen.
Menschliches Editing bleibt menschlich
Vale kann nicht entscheiden, ob eine Erklärung die richtige Frage beantwortet oder ein Beispiel das richtige mentale Modell vermittelt. Automatisiere Wiederholbares und nutze menschliche Aufmerksamkeit für Struktur, Evidenz und Klarheit.
Ein gutes Quality Gate ist fast langweilig: Es findet zuverlässig dieselben wichtigen Fehler.
Praxisbeispiel
Behandle „Vale als Quality Gate statt als Zeichensetzungspolizei“ als kleine Evaluation und nicht als Feature-Liste. Wähle drei echte Inhalte: eine einfache Seite, eine Seite mit Code oder strukturierten Daten und eine schwierige Seite mit Navigation, Wiederverwendung oder Lokalisierung. Teste alle drei und notiere, was leichter wird und welche neue Wartungslast entsteht.
Bewerte wiederkehrende Arbeit:
- versteht ein Autor die Quelle;
- sieht ein Reviewer einen sinnvollen Diff;
- weist ein Build-Fehler auf ein lösbares Problem hin;
- lässt sich Inhalt ohne manuelle Bereinigung verschieben, lokalisieren oder wiederverwenden.
Ein gutes Werkzeug reduziert Unsicherheit beim Schreiben, Review und Publizieren. Wenn Komplexität nur in fragile Konfiguration, Plugins oder das Wissen einer Person verschoben wird, gehört auch das in die Entscheidung.
Kurzer Redaktionscheck
- Beginne mit teuren Fehlern. Ein Linter kann Tausende Sätze in Sekunden prüfen, deshalb ist die Versuchung groß, jede Stilpräferenz zu kodieren.
- Behandle Regeln wie Code. Speichere Vale-Konfiguration und Vokabulare im Repository, reviewe Änderungen und benenne Regeln nach ihrer Absicht.
- Trenne Errors und Hinweise. Blockiere einen Build nur bei Problemen, die das Team wirklich als verpflichtend definiert hat.
- Pflege Terminologie zentral. Approved Names, Schreibweisen und Ersetzungen sollten an einer Stelle gepflegt werden.
