TunaSaiko/localize

Localize: Lokalisierung und Übersetzungsprüfung

0. Ein-Satz-Positionierung

Lokalisierung bedeutet nicht, Sprache A durch Sprache B zu ersetzen, sondern zuerst A in die Bedeutung zurückzuverwandeln und dann mit B neu zu schreiben. Der Wert dieses Skills liegt nicht darin, „flüssige Übersetzungen“ zu produzieren (das kann das Modell ohnehin), sondern darin, Sätze zu erfassen, die „flüssig, aber falsch“ sind, und die dabei getroffenen Entscheidungen als wiederverwendbare Glossare, Style-Sheets und Klärungslisten zu verankern.

Die „praktischen“ Fallbeispiele im Text stammen aus realen Projekten und wurden anonymisiert: Projekte und Produkte sind nicht namentlich genannt; Zitate, Stimmzahlen und Statistiken sind Originalaufzeichnungen; als „beispielhaft“ gekennzeichnete Wörter wurden ersetzt und sind nicht die Originale.

1. Eiserne Regeln (für alle Zugänge gleichermaßen gültig)

1. Die Quelldateien und Übersetzungsdateien des Benutzers werden nicht geändert. Alle Ergebnisse werden in das Arbeitsverzeichnis geschrieben (siehe §3). Die Prüfung gibt eine Mängelliste aus; der Benutzer wählt aus, ob die Änderungen übernommen werden.
2. Was nicht verstanden wird, wird nicht geraten. Es wird in die Klärungsliste aufgenommen. Bei Fragen, die im Translate-Zugang mehrere Stellen betreffen, wird zuerst der Benutzer gefragt; betrifft es nur eine Stelle, wird beim fertigen Text „(geschätzt)“ vermerkt.
3. Das Modell darf nicht behaupten, eine Quelle zu haben. Jede Aussage wie „Dieses Wort wird im Zielmarkt genau so verwendet“ muss entweder im Sprachpaar-/Locale-Paket belegt sein, mit WebSearch reale Beispiele aus ähnlichen Materialien im Zielmarkt gefunden haben oder als „ungeprüft“ gekennzeichnet werden.
4. Generierung und Prüfung erfolgen in getrennten Kontexten. Die Prüfung wird von einem unabhängigen Sub-Agenten durchgeführt; der Kontext der Generierung darf nicht seine eigene Übersetzung prüfen.
5. Die Faktenebene wird Skripten überlassen. Zahlen, Daten, Währungen, URLs, Einheiten und Zeichenkonventionen werden zuerst mit scripts/ geprüft; das Modell bearbeitet nur semantische Probleme, die die Skripte nicht erkennen. Das Modell hat eine hohe Fehlerrate bei Symbol-/Einheiten-Locale-Fehlern – es soll nicht nach Gefühl Locale-Fehler erkennen.
6. Jeder Fund wird mit Schweregrad bewertet, und es wird unterschieden zwischen „Fehler“ und „Präferenz“. Siehe §6.
7. Abschnittsweise prüfen, nicht das ganze Dokument auf einmal. Jeder Abschnitt hat etwa 1500 Zeichen im Quelltext; je länger der Text, desto weniger Fehler findet das Modell.
8. Umschreiben darf den Wortlaut ändern, nicht die Referenz. Satzstruktur, Wortwahl und Informationsreihenfolge dürfen geändert werden (bei Brand-Texten ist sogar Neuschreiben erlaubt), aber der Gegenstand, auf den der Quelltext verweist, darf nicht ausgetauscht werden – Zweck, Objekt, Menge, Subjekt. Werden falsche Fakten im Quelltext entdeckt (nicht existierende Produkte, unplausible Zahlen, Widersprüche), wird dies in die Klärungsliste aufgenommen und dem Autor zur Entscheidung vorgelegt; der Autor wird nicht korrigiert. Eine Änderung der Referenz erzeugt in der Regel neue Widersprüche.
9. In die Übersetzungsspalte gehören nur direkt veröffentlichungsfähige Strings. Platzhalter für Klärungen, Optionsvergleiche (Variante A/Variante B), interne Verweise („siehe unten…“), Breitenangaben und Bearbeitungshinweise gehören in separate Spalten oder separate Listen. Was keine Übersetzungseinheit ist, darf keine Zeile in der Übersetzungstabelle bekommen – z. B. „Dieses Label wird im Code zusammengesetzt, hat keinen i18n-Key“ oder „Diese Zahl ist fragwürdig“ – der gesamte Eintrag wird in die Klärungsliste verschoben, nicht eine Zeile mit einer Erklärung in der Übersetzungsspalte. Vor der Auslieferung wird scripts/deliverable_check.py ausgeführt; char_lint.py muss beim Prüfen der zweisprachigen Tabelle mit --tgt-col ausgeführt werden, sonst werden die Zeichen der Quelltextspalte fälschlich als Fehler in der Übersetzungsspalte gemeldet.
10. Wenn die Projekt-Startdatei und die Kernregeln in Konflikt geraten, wird dies aufgezeichnet und dann je nach Konfliktrichtung entschieden. Die zu Beginn erstellte Compliance-Tabelle, das Style-Sheet und das Glossar sind Entscheidungen zum damaligen Zeitpunkt, die Kernregeln sind projektübergreifende Entscheidungen; beide können in Konflikt geraten (typisch: Compliance-Tabelle fordert Abschwächung einer Passage, während diagnostics.md §10 bejahende Funktionsbeschreibungen verlangt). Zuerst die Konfliktrichtung bestimmen, dann entscheiden, wem gefolgt wird:
    • Die Startdatei ist strenger als die Kernregeln (verbotene Wörter, erforderliche Haftungsausschlüsse, konservativere Ausdrucksstärke) → der Startdatei folgen, auf eine Entscheidung warten. Compliance hat in der Regel einen Grund; die Kosten des weniger strengen Fehlers sind höher.
    • Die Startdatei enthält veraltete Fakten oder ist weniger streng als die Kernregeln (Spezifikationen geändert, Einschränkungen gelockert, eine von den Kernregeln geforderte Verarbeitung fehlt) → den Kernregeln folgen und die Startdatei aktualisieren. Beide Fälle erfordern: ① Festhalten in der Klärungsliste, Kennzeichnung als interner Regelkonflikt, nicht als Quelltextproblem; ② im Bericht angeben, welcher Regel gefolgt wurde und warum. Keine stille Wahl – die unabhängige Prüfung sieht Ihre Entscheidung nicht und wird sie als Verstoß erneut melden.

2. Input-Vertrag

Vor Arbeitsbeginn wird die folgende Tabelle gesammelt. Fehlende Angaben werden wie in der Spalte „Bei Fehlen“ behandelt und am Anfang des Berichts vermerkt.

Input	Erforderlich	Bei Fehlen
Quelltext (Dateipfad oder Einfügung)	Für Review/Translate erforderlich	Kein Quelltext → §5.3 Degradationsprozess
Übersetzung	Für Review erforderlich	—
Quell-Locale / Ziel-Locale	Erforderlich	Automatisch aus dem Text bestimmen, „automatisch bestimmt“ im Bericht vermerken
Materialtyp (siehe references/material-types.md)	Erforderlich	Einmal nachfragen; bleibt Antwort aus, nach Textmerkmalen bestimmen und vermerken
Szenario in einem Satz: Wer, in welcher Situation, liest dieses Material, um welche Entscheidung zu treffen	Erforderlich	Einmal nachfragen; bleibt Antwort aus, Standard aus Materialtyp nehmen und „Szenario nicht bestätigt“ im Bericht vermerken
Vorhandenes Glossar / Style-Sheet	Optional	Ein neues aus templates/ erstellen
Layout-Einschränkungen (Zeichenlimit, Rahmenbreite, ob String für Software)	Optional	Keine G7-Layout-Prüfung, im Bericht vermerken
Beispiele für ähnliche Materialien im Zielmarkt (für Translate-Zugang stark empfohlen)	Optional	„Szenario-Rekonstruktion ohne Beispielreferenz“ im Bericht vermerken
Übersetzungsquelle (menschlich / maschinell / KI / vorherige Version)	Für Review empfohlen	„Unbekannt“ vermerken
Autor/Quelle des Zieltexts (Muttersprachler des Zielmarkts / Nicht-Muttersprachler / unbekannt)	Bei fehlendem Quelltext erforderlich	Bei unbekannt degradieren und kennzeichnen
Aufwandstufe (siehe §8)	Optional	Standard: „Vollständig“

3. Arbeitsverzeichnis und Ergebnisse

Standardmäßig wird ein Unterverzeichnis <Quelldateiname ohne Endung>.l10n/ im selben Verzeichnis wie die Quelldatei erstellt. Gibt der Benutzer ein anderes an, wird dieses verwendet.

⚠ Die Verantwortung für das Speichern des endgültigen Berichts liegt beim Hauptdialog; der Sub-Agent gibt ihn als Text zurück. Praktische Erfahrung: In manchen Ausführungsumgebungen werden Schreibvorgänge von Sub-Agenten für Dateien wie findings.md/report/summary nach Dateinamen blockiert, während derselbe Skill in einer anderen Sitzung dieselben Dateinamen erfolgreich schreibt – die Blockierung variiert zwischen Sitzungen; keiner Seite kann etwas unterstellt werden. → Der Sub-Agent gibt Inhalte als Text zurück; der Hauptdialog speichert sie selbst und verifiziert sie (ls -lT + Zeilenanzahl). Bei Schreibfehlern darf der Sub-Agent nicht umbenennen oder mit Bash umgehen – das bedeutete, ein anderes Tool zu verwenden, um die gerade erlassene Blockierung zu umgehen. Zwischenergebnisse (list-a.md, scripts-report.md, open-questions.md usw.) sind nach praktischer Erfahrung nicht eingeschränkt und können direkt geschrieben werden.

Attributionsdisziplin: Vor der Behauptung „Die Umgebung hat mich blockiert“ zuerst Isolationsexperimente durchführen (jeweils einmal mit anderem Namen, Verzeichnis und Umfang). Gibt es in derselben Ausführung Gegenbeispiele (andere Dateien wurden geschrieben), kann die Ursache nicht der Umgebung zugeschrieben werden. Praktische Erfahrung: Der Hauptdialog behauptete „Es wurde nicht blockiert, weil du nicht geschrieben hast“, der Sub-Agent bewies mit drei Sonden, dass der Hauptdialog falsch lag. Derjenige, der das Experiment durchführt, hat Recht.

Datei	Inhalt
00-brief.md	Szenario in einem Satz, Materialtyp, Sprachpaar und Locale, diesmalige Abkürzung, Aufwandstufe, Strategie-Switches für Leerzeichen usw., Input-Mängel
glossary.md	Glossar (Vorlage templates/glossary.md), mit Ablehnungsgründen und Status
style-sheet.md	Style-Sheet (Vorlage templates/style-sheet.md), ausgehend von Locale-Paket-Standardwerten
open-questions.md	Klärungsliste (Vorlage templates/open-questions.md)
scripts-report.md	Ausgaben der R1-Skripte
findings.md	Prüfliste der Befunde (Vorlage templates/findings-report.md). Verantwortung für das Speichern liegt beim Hauptdialog, nicht beim Sub-Agenten, siehe unten
draft.<locale>.md	Übersetzungsentwurf aus dem Translate-Zugang (mit „(geschätzt)“-Markierungen)
decisions.md	Entscheidungsprotokoll für das gesamte Dokument (Terminologie, Symbole, Sprachstil, Schlüsselentscheidungen)

4. Vier Dinge vor Arbeitsbeginn + Laden der Regelpakete

In dieser Reihenfolge ausführen und in 00-brief.md notieren:

1. Szenario in einem Satz (§2), dann sofort zu einem Satz von „durchfallfähigen“ Kriterien entfalten.

   Praktische Lektion: Ein reiner Szenario-Satz reicht nicht. In einem Geschäftsvorschlag-Projekt war das Szenario sehr konkret (Leseridentität, Lesezeit und die zu treffende Entscheidung wurden genannt) und wurde sogar wörtlich in den Prompt des Terminologie-Entscheidungs-Agenten übernommen – trotzdem wurden mehrere Schlüsselbegriffe von Muttersprachlern abgelehnt; eine spätere Zählung ergab, dass nur 9 von 60 Glossareinträgen eine Begründung enthielten, die auf „Wer liest“ Bezug nahm. Das Szenario war ein Leitspruch, aber es floss in keines der „Besteht das oder nicht“-Kriterien ein.

   Daher muss das Szenario in die folgende Tabelle gegossen und in 00-brief.md geschrieben werden; jede spätere Entscheidung wird daran gemessen:

   Entscheidungstyp	Prüfung mit dem Szenario (muss „durchgefallen“ lauten können)
   Wortwahl	Bei der Suche das Szenario in Suchbegriffe und Suchwörter zerlegen (Materialtyp + Leseridentität). Wird nach Einschränkung kein Beispiel gefunden = ungeprüft, kein breiteres Suchverfahren zur Umgehung erlaubt. Siehe diagnostics.md §7, erste Hürde
   Zahlen・Einheiten・Währungen	„Kann dieser Leser innerhalb dieser Lesezeit beim Überfliegen sofort ein Gefühl für die Menge bekommen?“ – Praktisch passiert: Szenario lautete „in mehreren zehn Minuten lesen“, aber es wurde entschieden, keine Yen-Umrechnung vorzunehmen; drei Muttersprachler sagten wörtlich, dass sie „wegen der Notwendigkeit jedes Mal zu rechnen aufhören zu lesen“ würden
   Sprachebene	„Wirkt dieses Wort in den alltäglichen Dokumenten dieses Lesers (Due-Diligence-Bericht/Spezifikationen/interner Genehmigungsantrag) unpassend?“ Wenn ja, durch ein Synonym derselben Sprachebene ersetzen, aber nicht gleich die Bedeutung abschwächen. Siehe diagnostics.md §10b
   Struktur・Reihenfolge	„Er muss innerhalb dieser Lesezeit diese Entscheidung treffen; in welcher Reihenfolge braucht er die Informationen?“ Weicht die Reihenfolge vom Quelltext ab, in die Klärungsliste aufnehmen
   Nicht übersetzen	„Wirkt die Originalform (englische Zwischenüberschrift, Fremdwährung, Spezifikationsname) auf diesen Leser professionell oder fremd?“ Praktisch: Eine original erhaltene englische Zwischenüberschrift wurde als „Eindruck, eine ausländische Vorlage direkt zu verwenden“ bewertet

   Kriterien müssen scheitern können, um Kriterien zu sein. Ein Kriterium, das nicht beantworten kann, „Wie sieht das Durchfallen aus?“, ist keine Prüfung.

2. Die diesmalige „billige Entsprechung“-Abkürzung notieren. Jedes Sprachpaar hat eine scheinbar legitime Abkürzung: Es gibt eine oberflächliche Ebene (Wortform/Schriftform/Wortstellung), die „eins-zu-eins abbildbar“ aussieht, während die wirklichen Unterschiede tiefer liegen (Bedeutungsvarianten/regionale Wörter/Syntax). Je nützlicher die Abbildungstabelle, desto gefährlicher. Aus dem ersten Abschnitt des Sprachpaar-Pakets kopieren oder (falls kein Paket vorhanden) das Modell eine hypothetische Abkürzung schreiben lassen.

3. Regelpakete laden:

Paket	Pfad	Bei Fehlen
Sprachpaar-Paket (richtungsabhängig)	references/pairs/<src>-<tgt>.md, z. B. zh-ja.md	Modell schreibt eigene Abkürzungshypothese; G3/G6-Konfidenz degradiert; Berichtskopf: „Kein Sprachpaar-Paket“
Ziel-Locale-Paket	references/locales/<locale>.md, z. B. ja-JP.md	Style-Sheet aus leerer Vorlage; G5-Konfidenz degradiert; Berichtskopf: „Kein Locale-Paket“
Materialtyp-Regeln	references/material-types.md	—

Vorhandene Pakete: pairs = zh-ja (vollständig), ja-zh, en-ja, ja-en, zh-en, en-zh (Keime); locales = ja-JP (vollständig), zh-CN, zh-TW, en-US, en-GB (Keime). Keim-Pakete enthalten nur belegte Inhalte; fehlende Teile werden explizit benannt. 4. Glossar, Style-Sheet und Klärungsliste anlegen. Das Glossar wird beim Arbeiten erweitert; jeder Begriff erhält einen Eintrag; das Style-Sheet wird von den Locale-Paket-Standardwerten kopiert und dann projektspezifisch angepasst; die Klärungsliste wird ab dem ersten Satz geführt.

5. Drei Zugänge

5.1 Review: Prüfung vorhandener Übersetzungen (Quelltext + Übersetzung vorhanden)

Dies ist die am leichtesten falsch zu machende Form; die Versuchung ist, „nur die Übersetzung zu lesen und nach Fehlern zu suchen“. Empirische Schlussfolgerung: Ein einsprachiger Durchgang allein ist am schlechtesten; ein zweisprachiger Vergleich ist zwingend erforderlich; vom Zieltext ausgehen; die Reihenfolge der beiden Durchgänge ist frei.

R0 Eingaben sammeln (einschließlich Autor/Quelle des Zieltexts) → 00-brief.md schreiben → Regelpakete laden → die drei Dinge anlegen
R1 Skripte ausführen (§7): fact_check / char_lint / length_estimate / term_coverage / **distribution_check** → scripts-report.md
    **`distribution_check` muss vor dem einsprachigen Durchgang ausgeführt werden**: Es meldet die Verteilung im gesamten Dokument, während der einsprachige Durchgang elementweise vorgeht;
    erst mit den Verteilungsdaten weiß der einsprachige Durchgang, wo er hinschauen muss.
R2 Abschnittsweise ausrichten: Quelltext und Übersetzung absatzweise abgleichen, jeder Abschnitt ≤ ca. 1500 Zeichen im Quelltext, nummerieren S01, S02…
R3 Einsprachiger Durchgang (unabhängiger Sub-Agent, nur Übersetzung + Locale-Paket + Szenario):
    Stellen markieren, die „nicht wie von einem Muttersprachler geschrieben“ klingen, vier Triggerpunkte, Sprachbruch
    → **Original in `review/list-a.md` schreiben** (keine Zusammenfassung)
    → **Hauptdialog prüft Dateiexistenz, Zeilenanzahl ≥ Anzahl der Kandidaten**; bei Fehlschlag R3 wiederholen; nicht mit Zusammenfassung fortfahren
R4 Zweisprachiger Durchgang (unabhängiger Sub-Agent, abschnittsweise Quelltext + Übersetzung + Sprachpaar-Paket + zutreffende Glossareinträge):
    Fünf Fehlerarten, die nur im Vergleich sichtbar sind + modellspezifische Fehler (fehlende Sätze/hinzugefügte Details/übermäßige Glättung) + Informationsgranularität zählen
    → Ausgabe: list-B
R5 Zusammenführen, Deduplizieren, Schweregrad nach §6 bestimmen, Empfehlung in drei-Optionen-Format nach §6 schreiben
    **Nach dem Zusammenführen muss eine Zeile stehen: list-A hat N Einträge, davon sind M in die endgültige Liste eingegangen.**
    Die Befunde des einsprachigen Durchgangs komplett auszusortieren ist ein Prozessfehler, keine „Unwichtigkeit“ – siehe §5.5.
R6 Überprüfung durch einen Skeptiker (unabhängiger Sub-Agent, **muss Read/grep-Fähigkeit haben**): Jeden Eintrag critical/major einzeln prüfen,
    im Zweifel standardmäßig herabstufen; einmal gemäß Empfehlung umschreiben; wenn danach keine deutliche Verbesserung, auf neutral herabstufen;
    Praktische Erfahrung: Etwa die Hälfte der critical/major-Einträge wird herabgestuft, und bei manchen wird die Argumentation durch grep direkt widerlegt
    **Der Skeptiker stuft nur herab, er übersieht keine Fehler.** Die von ihm nicht geprüften minor-Einträge müssen dennoch behandelt werden, siehe §5.5.
R7 findings.md schreiben; glossary.md / open-questions.md / decisions.md aktualisieren
R8 Dem Benutzer vorlegen: Zuerst projektweite Entscheidungen zur Festlegung durch den Benutzer auflisten, dann die Liste der Befunde zum Ankreuzen; Anwendung erst nach Ankreuzen

Die Sub-Agent-Prompt-Vorlagen für R3/R4/R6 befinden sich in references/subagent-prompts.md; sie müssen in sich geschlossen sein (Dateipfad, Szenario und Abkürzung enthalten, nicht vom vererbten Kontext abhängig). Der absolute Pfad dieses Skills ist ${CLAUDE_SKILL_DIR}. Vor dem Versenden müssen alle {{skill_dir}} in der Vorlage durch diesen Pfad ersetzt werden, sonst kann der Sub-Agent die Sprachpaar-/Locale-Pakete nicht lesen. (Falls oben immer noch wörtlich ${CLAUDE_SKILL_DIR} steht und nicht durch einen Pfad ersetzt wurde – z. B. in anderen Tools wie Codex – verwenden Sie den absoluten Pfad des Verzeichnisses, in dem diese SKILL.md-Datei liegt; für andere ${CLAUDE_SKILL_DIR} in dieser Datei gilt dasselbe.)

5.5 Die Befunde des einsprachigen Durchgangs dürfen beim Zusammenführen nicht verdunsten

Dies ist eine praktisch erlebte Falle, keine theoretische Sorge. In einem Projekt für eine SaaS-Landingpage wurden 8 von 10 Rückmeldungen von Muttersprachlern bereits im einsprachigen Durchgang gemeldet, davon 6 niemals vom Skeptiker geprüft – weil beim Zusammenführen nur aus den Befunden des zweisprachigen Durchgangs (fehlende Übersetzung/Referenzabweichung/Terminologie) Kandidaten ausgewählt wurden, und die Lesbarkeitsbefunde des einsprachigen Durchgangs komplett aussortiert wurden. Der einsprachige Durchgang existiert nur, um „klingt wie übersetzt“ zu erfassen – seine Ergebnisse wurden vor der Prüfung verworfen.

Die Ursache ist eine strukturelle Überlagerung von drei Faktoren: ① Die Befunde des einsprachigen Durchgangs sind fast alle minor (das ist die Definition von minor); ② Der Skeptiker prüft per Design nur critical/major, minor gelangen nie in die Prüfung; ③ Die Schweregradtabelle bewertet einzelein, ein einzelner „beeinträchtigt das Verständnis nicht“, aber mehrere im selben Satz bedeuten „dieser Satz klingt wie übersetzt“ – kein Schritt summiert sie.

Vier feste Aktionen (in der Reihenfolge des Prozesses):

• A. list-A muss gespeichert und vom Hauptdialog verifiziert werden. Eine Zusammenfassung ersetzt nicht das Original – die Kreuzprüfung in §9.1 erfolgt elementweise mit list-A; nur die Zusammenfassung bricht die Kette, und später kann nicht mehr geprüft werden, „Haben wir das ursprünglich gemeldet oder nicht?“. Die Regel „muss gespeichert werden“ allein reicht nicht: In der Praxis wurde nicht gespeichert, weil die Sub-Agent-Rückschreibung durch einen API-400-Fehler unterbrochen wurde – die Regel kann Netzwerkfehler nicht verhindern. Daher ist dies eine Aktion des Hauptdialogs selbst – nach R3 prüft der Hauptdialog selbst mit wc -l, ob die Datei vorhanden und die Zeilenanzahl korrekt ist, bevor er zu R5 übergeht. (Der Agent sagt „erledigt“, der Hauptdialog muss selbst prüfen.)
• B. Dichte-Upgrade. Derselbe String wird vom einsprachigen Durchgang ≥3 Mal gemeldet, unabhängig von der Schwere der einzelnen Meldung, wird der gesamte String als T5-Neuschreibkandidat eingestuft. Begründung: Drei unabhängige Fehler in einem Satz können durch Einzelkorrekturen nicht behoben werden; Neuschreiben ist schneller.
• C. „Neuschreiben ist schneller“ und „unverständlich“ vom einsprachigen Durchgang sind harte Signale. Sagt der einsprachige Durchgang über einen Abschnitt „個別修正より書き直しが早い“ (Neuschreiben schneller als Einzelkorrekturen) oder „vollkommen unverständlich“, geht es direkt zu T5, ohne Schweregradfilter. Dies ist die einzige starke Aussage, die der einsprachige Durchgang aus muttersprachlicher Perspektive machen kann, und darf nicht als minor behandelt werden.
• D. Überlebensrate beim Zusammenführen melden. Die R5-Ausgabe muss eine Zeile enthalten: „list-A N Einträge → endgültige Liste M Einträge“. Ist M/N deutlich niedrig, wird zurückgegangen und geprüft, ob wieder nur Befunde aus dem zweisprachigen Durchgang ausgewählt wurden.

Warum wird der Skeptiker nicht auch für minor zuständig gemacht?: Das würde seine Aufgabe verwässern. Seine Aufgabe ist die Herabstufung (Verhinderung von Überbewertung), nicht die Nachsorge. Das Übersehen von Fehlern wird durch die obigen vier Aktionen auf der Speicher- und Zusammenführungsebene gelöst, nicht durch die Prüfungsphase.

5.6 Gruppenebenen-Befunde dürfen nicht durch Änderung eines Mitglieds als „behoben“ betrachtet werden

Praktisch erlebt, und zwar mit negativem Ergebnis. In einem realen Projekt hatte eine Gruppe von vier Optionen jeweils eine Beschriftung; der einsprachige Durchgang meldete „Die Achsen der vier Optionsbeschriftungen sind nicht ausgerichtet“ – die vier Beschriftungen bezogen sich auf Verwendungszweck, Empfehlungsgrad, Qualität und Spezifikation. Dies war ein Befund über die vier als Gruppe. Die damalige Behandlung bestand darin, nur die auffälligste zu überschreiben. Ergebnis: Die Achse blieb immer noch nicht ausgerichtet (die anderen drei blieben unverändert), und die geänderte Beschriftung wurde in einem späteren Blindtest mit drei Prüfern einstimmig als die schlechteste der drei Versionen bewertet, schlechter als das Original vor der Änderung. Die Änderung eines Mitglieds hat weder das Gruppenproblem gelöst noch ein neues Einzelproblem vermieden.

Kriterium: Enthält die Beschreibung des Befunds Wörter wie „nicht ausgerichtet“, „nicht einheitlich“, „nicht parallel“, „inkonsistenter Stil“, „zwischen diesen“ – das Subjekt ist Plural – dann ist es ein Gruppenebenen-Befund.

Zwei legitime Behandlungen, keine dritte:

1. Die ganze Gruppe gemeinsam ändern, dann die ganze Gruppe gemeinsam prüfen (Layout, Breite, Achse, Sprachebene als Gruppe betrachten).
2. Die ganze Gruppe unverändert lassen und den Befund in die Klärungsliste aufnehmen mit dem Vermerk „Muss als ganze Gruppe neu geschrieben werden, in dieser Runde nicht erfolgt“.

Nicht das auffälligste Mitglied der Gruppe ändern und dann so tun, als sei das Problem gelöst. Das korrekte Ergebnis eines Gruppenebenen-Befunds ist ein Ersatz für die gesamte Gruppe, nicht für eine einzelne.

5.6a Nach dem Neuschreiben einer gesamten Gruppe muss das Style-Sheet erneut geprüft werden – die Gruppenreparatur darf nicht gegen bestehende Einschränkungen für diese Mitglieder verstoßen

§5.6 sagt „Die ganze Gruppe ändern“, sagt aber nur die Hälfte. Praktisch: Nach §5.6 wurde die gesamte Gruppe der Beschriftungen neu geschrieben; die Achse war einheitlich und die Breite war reduziert (von 3,00× auf 1,43×) – der Blindtest mit Muttersprachlern verlor jedoch gegen „nur die genannte zu ändern“ – zwei lehnten mit der Begründung ab: 「体言止めで短く揃えるのが日本のUI標準」(Substantivstopps zum kurzen Ausrichten sind UI-Standard in Japan), und diese Regel stand bereits im Style-Sheet dieses Projekts. Die Achse war repariert, aber die Sprachkonvention wurde verletzt. Die Ursache lag nicht in der Regel, sondern darin, dass der Prompt die Einschränkungen aus dem Gedächtnis wiedergab, nicht den Originaltext des Style-Sheets kopierte.

Feste Aktion: Vor dem Umschreiben eines bereits festgelegten Strings zuerst fragen: „Von welchen Entscheidungen wird dieser String bereits regiert?“, und den Originaltext dieser Einträge in den Prompt kopieren – nicht aus dem Gedächtnis wiedergeben. Mindestens diese vier Kategorien müssen kopiert werden:

Was kopieren	Woher kopieren
Zutreffende Glossareinträge	glossary.md
Anwendbare Style-Sheet-Zeilen (Sprachebene, Endung, Interpunktion, Leerzeichen, Breitenbeschränkungen)	style-sheet.md ← diese Kategorie wird am leichtesten vergessen
Die festgelegte Schreibachse dieser parallelen Gruppe	style-sheet.md „Schreibachse für parallele Gruppen“-Zeile
Szenario-Satz und diesmalige Abkürzung	00-brief.md

T3 hatte diese Anforderung bereits (§5.2 „Jeder Abschnitt enthält zutreffende Glossareinträge + Style-Sheet + Szenario + Abkürzung“). Die Falle waren die außerplanmäßigen Umschreibaufgaben – das Reparieren von Muttersprachler-Feedback, das Erstellen einer Fusion-Version, das Ergänzen einer fehlenden Übersetzung. Diese Aufgaben durchlaufen nicht die T3-Nummerierung und werden leicht als „mal schnell ändern“ ohne Payload betrachtet. Sie benötigen genauso das volle Payload wie T3.

Wenn die Achse einer parallelen Gruppe mit der „Referenz“ kollidiert, hat die Referenz Vorrang – die Achse wird gebrochen, die Bedeutung nicht geändert. Praktisch: Drei von vier Feldern im Quelltext waren A + B, eines war A / B (oder); das Style-Sheet legte den Verbinder für diese Gruppe auf 「＋」fest. Die Generierung folgte der Achse und machte aus dem „oder“ des einen Feldes ein „und“ – um der Layout-Einheitlichkeit willen wurde die Bedeutung des Quelltextes geändert, genau was Regel 8 verbietet. Die Achse ist die Wortebene, die Referenz ist die Faktenebene. Im Konfliktfall wird dieses Feld die Achse brechen (「／」verwenden) und im Bericht wird begründet, warum. Layout-Konsistenz darf nicht über die Referenz gestellt werden – dies muss auch als Prüfpunkt auf der Review-Seite aufgeführt werden, da es vollkommen lesbar klingt und nur im Vergleich mit dem Quelltext sichtbar wird.

Prüfschritt: Nach dem Neuschreiben der gesamten Gruppe wird die neue Gruppe Element für Element gegen das Style-Sheet abgehakt, und dann wird bestätigt, dass die neue Gruppe keine Probleme eingeführt hat, die die alte nicht hatte (Breite, Sprachebene, Interpunktion, Konsistenz mit benachbarten Gruppen). length_estimate.py --siblings kann nur die Breite prüfen; die Sprachebene muss manuell geprüft werden.

Nebenprodukt: Die Diskrepanz innerhalb der Gruppe ist maschinell prüfbar. Bei parallelen Gruppen (der Key ändert nur ein Token, z. B. plan_lite_/standard_/pro_/max_description, beipielhaft) wird die Spanne der Breiten von length_estimate.py --siblings aufgelistet. In einem realen Projekt hatten 5 von 6 parallelen Gruppen eine Spanne ≤1,67×, nur die geänderte Gruppe hatte 3,00×. Das Skript listet nur auf, bewertet nicht – der Schwellenwert hat keine projektübergreifende Grundlage und sollte nicht willkürlich festgelegt werden.

5.2 Translate: Übersetzung aus dem Nichts (nur Quelltext)

T0 Eingaben sammeln (nach Möglichkeit Beispiele für ähnliche Materialien im Zielmarkt anfordern) → 00-brief.md → Regelpakete laden
T1 Volltext-Voranalyse, ohne zu schreiben: Volltext lesen → Terminologie-Kandidaten extrahieren → Klärungsliste erstellen
    Fragen, die mehrere Stellen betreffen → zuerst den Benutzer fragen; betrifft es nur eine Stelle → „(geschätzt)“ markieren und fortfahren
T2 Terminologie-Entscheidung (drei Hürden: bereits vorhanden? Überschneidung? passt ins Layout?) → glossary.md
    **Begriffe wie „Bestimmtheitsstufe“, „Statusabzeichen“ – die ein eigenes System bilden – müssen in ähnlichen Materialien des Zielmarkts nach vorhandenen Bezeichnungen gesucht werden.**
    Praktisch: Um eine Überbewertung zu verhindern, wurde eine vierstufige Skala entworfen; die stärkste Stufe wurde auf `検証済み` (geprüft) festgelegt – **Design richtig, Wortwahl falsch**.
    Drei Muttersprachler wiesen einhellig darauf hin, dass der Standardbegriff für das Traktions-Abzeichen in Investmentmaterialien `実績` (Erfolge) ist; `検証済み` würde an Drittanbieter-Zertifizierung denken lassen.
    **Ein in sich konsistentes System ist nicht gleich dem im Zielmarkt verwendeten System.**
    **Die Quelle eines Begriffs muss zusammen mit „Für wen ist dieses Material bestimmt?“ aufgezeichnet werden – Ein Begriff existiert in der Zielsprache ≠ Der Ziel-Leser versteht ihn auf Anhieb.**
    Praktisch **viermal dasselbe Muster**: Vier Begriffe wurden als „geprüft“ eingestuft, basierend auf einer Produktseite eines anderen, einem allgemeinen Wörterbuch, einer selbst entworfenen Skala und einem Technologieanbieter-Blog –
    Ergebnis: Einer war eine Funktion, die ein anderes Produkt beherrschte, das Materialprodukt jedoch nicht; einer wurde im Japanischen nur in einem anderen Bereich verwendet;
    einer war in den Materialien des Ziel-Lesers eine zu große Darstellung; einen verwendeten Technik-Leser häufig, Geschäftsleser fast nie.
    **Gemeinsame Ursache**: Leser der Quelle und Leser des Materials sind nicht dieselbe Gruppe.
    → Das Quellenfeld muss als `Quelle (Leserprofil)` geschrieben werden: `Technologieanbieter-Blog (Leser = Ingenieure)` und
    `Geschäftsplan für Investoren (Leser = Investorenverantwortliche)` **sind zwei verschiedene Dinge und können einander nicht ersetzen**.
    Bei der Überprüfung werden zuerst Materialien **für dieselbe Lesergruppe** gesucht.
    **Die Auswahl der Einträge darf nicht nur nach „dieses Wort sieht schwer aus“ erfolgen; zuerst muss die Häufigkeit geprüft werden**:
    `term_coverage.py cover` listet hochfrequente Inhaltswörter im Quelltext auf, die nicht im Glossar sind. **Hochfrequente + wiederholt an parallelen Positionen vorkommende Wörter müssen einen Eintrag haben**,
    selbst wenn sie überhaupt nicht schwer aussehen; wenn die Entscheidung gegen einen Eintrag fällt, wird eine Zeile „Keine Vereinheitlichung erforderlich, Grund ist …“ eingefügt, damit der Nächste es sieht.
    Praktisch übersehen: `团队` (Team) (9 Stellen) und `企业` (Unternehmen) (10 Stellen) wurden als „sieht nicht schwer aus“ nicht aufgenommen; in der Übersetzung erschienen jeweils zwei verschiedene Versionen,
    während **die im Glossar enthaltenen Wörter zu 100 % konsistent waren**. Kein Eintrag → keine Abdeckung durch die automatische Konsistenzliste → grep-Prüfung vor Auslieferung findet es nicht →
    zweisprachiger Durchgang „wurde gemäß Glossar verwendet?“ hat kein Glossar zum Überprüfen. **Eine Ebene fehlt, vier Ebenen sind leer.**
    Das Style-Sheet wird ausgehend von den Locale-Paket-Standardwerten erstellt → style-sheet.md
    **Vor Abschluss muss ein Konsistenzabgleich zwischen den Entscheidungsdateien durchgeführt werden**: Ein und dasselbe Wort muss in glossary / style-sheet / decisions
    an allen drei Stellen gleich geschrieben sein. Praktisch erlebt – glossary setzte `一括エクスポート` (Stapel-Export) fest,
    das Style-Sheet schrieb für dieselbe parallele Gruppe jedoch `まとめて書き出し` (gesammelt exportieren) (Wörter sind beipielhaft); die Generierungsseite musste sich für eine entscheiden,
    aber jede Wahl würde auf der Review-Seite als Fehler gemeldet. **Zwei Entscheidungsdateien im Konflikt – die nachgelagerte Seite hat keine Lösung.**
    Maschinelle Prüfung: Die Spalte „Zielsprachwort“ des Glossars wird einzeln mit grep in den beiden anderen Dateien gesucht; taucht eine andere Form auf, wird gestoppt und vereinheitlicht.
T3 Abschnittsweise generieren (jeder Abschnitt enthält die zutreffenden Einträge aus demselben Glossar + Style-Sheet + Szenario + Abkürzung):
    ① Bedeutungsentnahme: Was will dieser Satz eigentlich sagen (jenseits des Wortlauts)
    ② Szenario-Rekonstruktion: Wie würde eine Person im Zielmarkt in diesem Szenario schreiben (falls Beispiele vorhanden, Satzstruktur und Sprachebene damit vergleichen)
    ③ Sprachgefühl-Verfeinerung: Sprachebene, Länge, Konsistenz mit dem gesamten Dokument
    Ständige Selbstfrage: Wähle ich dieses Wort, weil der Quelltext auch diese Form hat (Übersetzung), oder weil diese Art von Material so geschrieben wird (Lokalisierung)?
    → draft.<locale>.md
T4 Für (Quelltext, Entwurf) die R1–R7 aus §5.1 durchführen (unabhängiger Kontext)
T5 Entwurf gemäß Befunden überarbeiten; Konsistenz-Scan durchführen (tatsächliche Verwendung jedes Glossarbegriffs im gesamten Text);
    **erneut `distribution_check` ausführen** – Einzelrevisionen ändern die Verteilung im gesamten Dokument; nach der Überarbeitung muss die Verteilung erneut geprüft werden
T6 Ausgabe: Entwurf + Glossar + Style-Sheet + Klärungsliste + Entscheidungen (+ Längenbericht)

5.2b Adapt: Struktur-/Genre-Neukonzeption nach Autorisierung (MVP)

Translate erlaubt bereits das Ändern von Satzstrukturen und Umstellen von Wortlaut; der Unterschied von Adapt liegt in der vorherigen Autorisierung + prüfbaren Struktur-/Genre-Neukonzeption. Sagt der Benutzer nur „übersetzen/lokalisieren“, wird weiterhin Translate verwendet; erst wenn der Benutzer „für den japanischen Markt neu machen/nach japanischer Firmenschreibweise umschreiben/Vorschlag neukonzipieren“ sagt und dies ausdrücklich autorisiert, wird Adapt verwendet.

Voraussetzungen: Beispiele für ähnliche Materialien, die zum Ziel-Leser passen, Autorisierungstabelle des Autors, Erfolgskriterien. Fehlt eines der drei Elemente, wird Adapt gestoppt oder auf Translate zurückgegriffen; das Modell darf nicht selbst entscheiden.

Was neu konzipiert werden darf: Titel und Informationsebenen, Reihenfolge von Absätzen/Schritten, Zusammenführen/Aufteilen von Ausdruckseinheiten, Darstellungsebenen des Zielmarktes, autorisierte Branchen-/Genre-Ausdrücke, Darstellungsform (Prosa ↔ Tabelle/nummerierte Schritte, AUTH-08) – dieser Punkt wird separat aufgeführt, da Prosa-zu-Tabelle einen Satz in mehrere Zellen aufteilt, wobei Bedingungen und Negationen am leichtesten verloren gehen. Was niemals geändert werden darf: Zahlen, Daten, Subjekt, Objekt, Menge, Zeit, Funktion, Preis, kostenlose/kostenpflichtige Bedingungen, Wirkungsintensität, rechtliche Bedeutung, Negationen und Einschränkungen.

Prozess: A0 Input/Autorisierung → A1 Zielmarkt-Konventionen → A2 Faktentabelle → A3 Maximal zwei Strukturvorschläge und auf Autorenfreigabe warten → A4 Abschnittsweise Neukonzeption → A5 Unabhängige Prüfung auf Fakten/Referenz und Natürlichkeit → A6 Autorenabnahme. Ohne Autorenfreigabe der Strukturvorschläge darf nicht generiert werden; ohne Autorenabnahme gilt es nicht als abgeschlossen.

Ergebnisse: authorization.md, market-conventions.md, fact-ledger.md, structure-options.md, adapt-map.md, decisions.md, open-questions.md, Endfassung; adapt-map unterstützt die Zuordnung einer Quelle zu mehreren Zielen und mehrerer Quellen zu einem Ziel. N≠M bedeutet nicht unbedingt Auslassung; muss durch die Zuordnung und die Faktentabelle verifiziert werden.

Betriebsanleitungen erfordern außerdem task-test.md: Erfolgsrate bei Schlüsselaufgaben darf nicht niedriger sein als bei Translate; natürlicher, aber den Benutzer leichter zum Scheitern bringend – dann gilt Adapt als fehlgeschlagen.

Zwei maschinelle Prüfungen (müssen durchgeführt werden, bevor fortgefahren wird):

# A3→A4: Nur generieren, wenn ein echtes Autoren-Freigabeereignis vorliegt
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py gate \
    --authorization <Autorisierungstabelle> --structure <Strukturvorschlag> --conventions <Marktkonventionen> [--map <adapt-map>]
# A4→A5: Mehr-zu-Mehr-Zuordnung und Faktengranulareins-zu-Eins-Umsetzung
python3 ${CLAUDE_SKILL_DIR}/scripts/adapt_check.py map \
    --source <Quelltext> --ledger <Faktentabelle> --map <adapt-map> --draft <Zieltext> \
    --authorization <Autorisierungstabelle> --glossary <Glossar>

Quelltext und Zieltext müssen mit Einheitenankern versehen werden (<!-- SRC-001 --> / <!-- TGT-001 -->), sonst ist eine einheitenweise Prüfung nicht möglich. gate Exit-Code 2 = Keine Generierung erlaubt. Es blockiert: AUTH-07 wurde entsperrt, „autorisiert“ markiert ohne Autorenbestätigung, Genehmigungsvorschlag noch als Platzhalter A / B / nicht genehmigt, keine verifizierten Beispiele für den Ziel-Leser, map verweist auf nicht autorisierte AUTH. „Das Modell hat selbst „genehmigt“ in die Tabelle eingetragen – genau das soll diese Prüfung verhindern. map Exit-Code 1 = Blockierung. Es blockiert: Hash der Faktentabelle stimmt nicht mit Quelltext überein (nach Generierung die Tabelle geändert), Quell-/Zieleinheit nicht zugeordnet oder keine Quelle, Granulat der Faktentabelle hat keine Zeile in der Umsetzungstabelle (Mapping-Lücke), Umsetzungstabelle hat den Quelltextwert der Faktentabelle geändert, der deklarierte Zielimplementierungs-String ist in der Zieleinheit nicht zu finden (Granulat beim Zusammenführen verloren gegangen), die Zielimplementierung des Subjekts stimmt nicht mit der Glossar-Übersetzung überein (Empfänger ausgetauscht), Zahlen/Daten/URLs existieren nur auf einer Seite (Fakten verloren oder hinzugefügt).

Was diese beiden Prüfungen beweisen können und was nicht, muss zusammen gesagt werden: Das Skript verifiziert nur, ob der deklarierte String wörtlich in der angegebenen Einheit erscheint, nicht, ob dieser String semantisch wirklich dieses Granulat ausdrückt – wird die Negation gelöscht und gleichzeitig in der Umsetzungstabelle in einen existierenden, irrelevanten String geändert, wird die maschinelle Prüfung dies übersehen. Eine weitere Lücke ist, dass die Zielseitenabdeckung nur bis zur Einheitenebene reicht: Es garantiert, dass jede Zieleinheit eine Quelle hat, nicht, dass jeder Satz innerhalb einer Einheit eine Quelle hat, so dass ein erfundener Satz in einer bereits zugeordneten Einheit vom Skript nicht gesehen wird (nur die Zahlen-/Daten-/URL-Ebene kann einen Teil abfangen). → Gegenmaßnahme: In der adapt-map muss manuell eine Tabelle mit „neu hinzugefügtem Text“ erstellt werden, die Überschriften, Fußnotenzeichen, Verweissätze und Zwischenüberschriften – alles, was keine Aussage aus dem Quelltext ist – einzeln aufführt und einer unabhängigen Prüfung übergibt. Ob die Semantik erhalten bleibt, unterliegt der unabhängigen Prüfung der Vorlage F; ob das Genre angemessen ist, unterliegt der Autorenabnahme. Skript bestanden ≠ Adapt bestanden.

Ausführliche Vorlagen und Prompts finden Sie in templates/authorization.md, templates/adapt-map.md und references/subagent-prompts.md (Vorlagen E/F).

Aktueller Überprüfungsstatus: Die Autorisierungstür und der Faktentabellenvertrag haben 32 automatisierte positive und negative Regressionen (evals/test_adapt_checks.py, Beispiele in evals/smoke/adapt/), einschließlich „2→1 Zusammenführung, alle Bedingungen erhalten – bestanden / eine Negation löschen – muss fehlschlagen / Empfänger wechseln – muss fehlschlagen / nicht autorisiert – keine Generierung“. Realwelt-Material (Joplin-Hilfedokumentation en→ja, Evernote-Abschnitt: 15 Einheiten → 9 Einheiten) hat A0–A4 bestanden: sowohl gate als auch map hatten 0 Blockierungen, fünf adversarial Manipulationen wurden alle blockiert (einschließlich „gleichzeitig den Text und die Deklaration ändern“ – Empfängertausch). A5 unabhängige Prüfung wurde durchgeführt (zwei Runden: Fallgrubenrunde + saubere Runde); A6 Autorenabnahme, Zielbenutzer-Aufgabentests und Muttersprachler-Durchlesen fehlen noch – diese drei müssen abgeschlossen sein, bevor Adapt als bestanden erklärt werden kann. Praktische Lektion: Die ersten fünf Probleme, die bei realen Materialien gemeldet wurden, waren alle auf Fehler in der Prüfung/Vorlage selbst zurückzuführen (Vorschlagsnamen auf einen einzelnen Buchstaben beschränkt, Zweitabellenformat der Konventionsdatei, englische Schreibweise von Zahlen, die Prüfung blockierte die von ihr selbst autorisierte Umwandlung „Prosa in nummerierte Schritte“, keine strukturelle Änderung erforderte zwingend einen Verweis auf die Autorisierung). Wenn die Prüfung bei der ersten Konfrontation mit realen Materialien Fehler meldet, ist zuerst die Prüfung zu verdächtigen.

5.3 Kein Quelltext (nur Übersetzung)

Ohne Quelltext können Auslassungen, Referenzverschiebungen, Zahlenfehlanpassungen und andere substanzielle Übersetzungsfehler nicht überprüft werden; möglich sind Sprachgefühl, interne Konsistenz und Schreibkonventionen. char_lint / term_coverage / distribution_check (Transkriptionsrate nicht anwendbar) und R3 ausführen; was nicht beurteilt werden kann, kommt in die Klärungsliste.

Aber die mit sourceLanguage angegebene Sprache ist nicht gleichbedeutend damit, dass der Textautor ein Muttersprachler dieser Sprache ist. Bei fehlendem Quelltext muss zu Beginn gefragt werden: „Von wem wurde dieser Zieltext geschrieben?“

• Von einem Muttersprachler des Zielmarkts → Die obigen Einschränkungen gelten; Lesbarkeitsprobleme dürfen nicht als Übersetzungsfehler ausgegeben werden.
• Direkt von einem Nicht-Muttersprachler geschrieben (Einzelentwickler, Auslands-Team selbst verfasster Werbetext) → Die Muttersprache des Autors ist der „unsichtbare Quelltext“, das entsprechende Paket pairs/<Autoren-Muttersprache>-<Zielsprache>.md laden und mit der Methode des zweisprachigen Durchgangs nach Mutterspracheninterferenzen scannen; falsche Freunde, Reste von Autoren-Muttersprachwörtern, nicht vereinheitlichte gleiche Konzepte können gefunden werden, aber im Bericht muss klar stehen, dass es sich um „Mutterspracheninterferenz“ handelt, nicht um eine Schlussfolgerung aus Quelltext-Übersetzungsvergleich.
• Autor unbekannt → Keine Spekulation über die Muttersprache des Autors; nur intern im Zieltext belegbare Probleme melden, zusätzlich „Autorquelle nicht bestätigt“ vermerken.

Praktisch (eine App, Zieltext direkt von einem Nicht-Muttersprachler verfasst): Der einsprachige Durchgang fand mehrere Reste von Autoren-Muttersprachwörtern; andere Strings derselben App verwendeten für dasselbe Konzept bereits idiomatische Ausdrücke, also waren dies intern belegbare Mutterspracheninterferenzen. Dies ist bei Einzelentwicklern/Auslands-Teams die Regel, keine Ausnahme.

5.4 Mehrsprachig parallel / kontinuierliche Aktualisierung (kurz)

Mehrsprachig parallel: Zuerst Source of Truth festlegen; Glossar um eine Spalte erweitern (Konzept | Sprache A | Sprache B …); Zahlen und Fakten in allen Versionen abgleichen (fact_check.py paarweise); Begründungen für „bewusst unterschiedlich“ aufbewahren. Kontinuierliche Aktualisierung: Glossar und Style-Sheet sind langfristige Assets und werden im Benutzerprojekt statt im temporären Verzeichnis .l10n/ abgelegt; neue Inhalte durchlaufen nur R1–R4.

6. Schweregrad, Format der Befunde, drei Optionen

… [gekürzt für die Übersetzung]