Fachbegriffe, Groß-/Kleinschreibung und übersetzte Bezeichnungen korrekturlesen
Prüfen Sie bei der Durchsicht technischer Dokumentationen jeden Begriff anhand einer expliziten Terminologietabelle, anstatt sich auf das Gedächtnis oder eine einzelne Groß-/Kleinschreibungsregel zu verlassen. Erfassen Sie die freigegebene Form, die Schreibweise und Groß-/Kleinschreibung, die Leser sehen sollten, zulässige Varianten, literale Code- oder API-Bezeichner sowie noch ausstehende Übersetzungsentscheidungen. Lesen Sie Fließtext, Schnittstellenbezeichnungen und Bezeichner anschließend als separate Elemente Korrektur. Diese Methode deckt inkonsistente Terminologie auf und schützt gleichzeitig Namen und Code, die exakt bleiben müssen.
Warum kann eine einzige Regel zur Groß-/Kleinschreibung nicht jeden Begriff klären?
Styleguides bieten nützliche Standardvorgaben, doch ein Produkt oder ein Fachgebiet kann über etablierte Namen verfügen, die eine abweichende Behandlung erfordern. Der Entwicklerleitfaden von Google empfiehlt standardmäßige US-amerikanische Groß-/Kleinschreibung sowie Satzschreibung (Sentence Case) für Überschriften, Listen und Tabellen, während offizielle Produktnamen und Codeformen unverändert beibehalten werden. Auch der Leitfaden von Microsoft bevorzugt Satzschreibung, reserviert die Großschreibung jedoch ausdrücklich für Eigennamen wie eigene Marken, Produkte und Dienste. Dieser gemeinsame Standard ist ein Ausgangspunkt, aber kein Beweis dafür, dass ein bestimmter Fachbegriff generisch ist. [Googles Leitfaden zur Groß-/Kleinschreibung](https://developers.google.com/style/capitalization) [Microsofts Leitfaden zur Groß-/Kleinschreibung](https://learn.microsoft.com/en-us/style-guide/capitalization)
Eine Begriffsliste kann eine andere Frage beantworten als eine allgemeine Seite zur Groß-/Kleinschreibung: welche Schreibweise oder Verwendung ein bestimmter redaktioneller Leitfaden für konkrete Begriffe bevorzugt. Die Begriffsliste von Google verweist Leser beispielsweise für nicht abgedeckte Einträge auf das bevorzugte Wörterbuch und unterscheidet Stilempfehlungen von der Überprüfung einer technischen Definition in autoritativer Dokumentation. Diese Trennung ist sinnvoll: Redaktionelle Konsistenz und fachliche Richtigkeit erfordern Belege aus Quellen, die für die jeweilige Fragestellung geeignet sind. [Googles Begriffsliste](https://developers.google.com/style/word-list)
Was gehört in eine Terminologietabelle für das Korrekturlesen?
Legen Sie für jeden Begriff, der inkonsistent geändert oder falsch übersetzt werden könnte, eine eigene Zeile an. Dieses hypothetische Beispiel veranschaulicht die Felder und die Entscheidungslogik; „Sync token“ und dessen Übersetzung dienen der Illustration und stellen keine Behauptungen über ein reales Produkt oder freigegebene Terminologie dar.
Die Aufgabe der Tabelle besteht darin, Entscheidungen und deren Grenzen festzuhalten. Eine zulässige Kleinschreibung sollte nicht stillschweigend zu einem zweiten Produktnamen werden; ein Bezeichner sollte nicht „korrigiert“ werden, um ihn an den Fließtext anzupassen; und eine ungelöste Übersetzung sollte sichtbar ungelöst bleiben. Wenn eine offizielle Quelle im Widerspruch zu einem lokalen Glossar steht, erfassen Sie den Konflikt und die Quelle der endgültigen Entscheidung, anstatt die Formen in einer unerklärten Liste zusammenzuführen.
Wie legen Sie die angezeigte Schreibweise und Groß-/Kleinschreibung fest?
Bestimmen Sie zunächst, worauf sich der Begriff bezieht: ein gewöhnliches Konzept, einen Marken- oder Produktnamen, eine UI-Bezeichnung oder einen literalen Bezeichner. Prüfen Sie die relevante Produktdokumentation oder das Glossar auf die offizielle Form. Wenden Sie dann die Stilregeln der Zielpublikation auf normalen Fließtext, Überschriften und Bezeichnungen an, wobei dokumentierte Ausnahmen für Namen und Bezeichner beibehalten werden. Google rät von unnötiger Großschreibung ab und warnt davor, Bedeutungsunterschiede allein durch Groß-/Kleinschreibung auszudrücken; Microsoft empfiehlt in seinem Ansatz der Satzschreibung ebenfalls Kleinschreibung, abgesehen von Satzanfängen und Eigennamen. [Googles Leitfaden zur Groß-/Kleinschreibung](https://developers.google.com/style/capitalization) [Microsofts Leitfaden zur Groß-/Kleinschreibung](https://learn.microsoft.com/en-us/style-guide/capitalization)
Gleichen Sie die Form anschließend gegebenenfalls mit der Begriffsliste und dem Wörterbuch der Zielorganisation ab. Halten Sie die Quelle und deren Version oder Prüfdatum fest, damit ein anderer Redakteur die Entscheidung nachvollziehen kann. Schließen Sie nicht von einer ansprechend wirkenden großgeschriebenen Schreibweise, einem Suchergebnis oder einer Übersetzung, die dem englischen Begriff ähnelt, auf einen offiziellen Status. Wenn Quellen uneins sind oder die Form nicht spezifizieren, kennzeichnen Sie die Zeile für eine Entscheidung, anstatt eine Vermutung als verbindliche Terminologie darzustellen.
Wie sollten Übersetzungen und Schnittstellenbezeichnungen geprüft werden?
Betrachten Sie Übersetzungen als eine Entscheidung über Bedeutung und Kontext, nicht als mechanische Umwandlung der Groß-/Kleinschreibung. Eine Bezeichnung kann durch die Benutzeroberfläche, etablierte lokalisierte Produktterminologie oder eine andere grammatikalische Form in der Zielsprache eingeschränkt sein. Vergleichen Sie den Kandidaten mit freigegebenen lokalisierten Materialien und dem Kontext, in dem die Leser darauf stoßen werden. Liegt keine autoritative lokalisierte Form vor, kennzeichnen Sie die Übersetzung als ungelöst und fordern Sie die entsprechende Terminologieentscheidung an; erfinden Sie kein vermeintlich offizielles Äquivalent.
Lesen Sie nach der Begriffsentscheidung die tatsächliche Bezeichnung direkt an Ort und Stelle Korrektur. Prüfen Sie, ob die Groß-/Kleinschreibung den Regeln der Zielsprache und dem geltenden Produkt- oder Hausstil entspricht. Halten Sie die Originalbezeichnung zusammen mit Quelle und Status im Begriffseintrag sichtbar, damit bei einer künftigen Bearbeitung eine vorläufige Übersetzung nicht fälschlicherweise für eine freigegebene gehalten wird. Wenn die Bezeichnung auch in Anleitungen referenziert wird, stellen Sie sicher, dass der Fließtext exakt denselben Wortlaut wie auf dem Bildschirm verwendet.
Wie schützen Sie Code- und API-Bezeichner?
Trennen Sie literale Zeichenketten vom redaktionellen Text, bevor Sie die Groß-/Kleinschreibung ändern. Vergleichen Sie Bezeichner Zeichen für Zeichen mit der relevanten API-Referenz, dem Schema, dem Code oder der Benutzeroberfläche. Behalten Sie Unterstriche, Groß-/Kleinschreibung, Abstände und Zeichensetzung dort bei, wo die Quelle sie definiert; stilistische Normalisierung gehört in die umgebende Erklärung, nicht in einen literalen Wert. Der Leitfaden von Google erlaubt ausdrücklich reine Großschreibung oder CamelCase-Formen in offiziellen Namen oder bei Verweisen auf Code, der diese verwendet. [Googles Leitfaden zur Groß-/Kleinschreibung](https://developers.google.com/style/capitalization)
Eine praxistaugliche Prüfung kennzeichnet geschützte Bezeichner in der Terminologietabelle und gleicht dann jedes Vorkommen mit dieser Referenz ab. Wenn ein Satz im Fließtext einen Begriff im Code-Format wie ein gewöhnliches Substantiv verwendet, entscheiden Sie, ob er in leserfreundlicher Formulierung erklärt werden soll, während der literale Bezeichner in Code-Formatierung intakt bleibt. Wenn die autoritative Definition selbst unklar ist, halten Sie die Unsicherheit fest; ein Styleguide kann weder das Verhalten einer API noch einen kanonischen Feldnamen festlegen.
Was ist ein verlässlicher Ablauf für das Korrekturlesen?
Dieser Ablauf ist eine Hilfe beim Korrekturlesen, keine automatische Übersetzung und keine universelle Regel für die Groß-/Kleinschreibung. Sein Nutzen liegt darin, jede redaktionelle Entscheidung nachvollziehbar zu machen: welche Form gewählt wurde, woher sie stammt, wo sie gilt und was noch entschieden werden muss. Für ein kurzes Dokument reicht möglicherweise eine kompakte Tabelle aus; bei einem umfangreichen Terminologiebestand behalten Sie dieselben Felder im etablierten Glossar-Workflow des Teams bei.