Tech-Docs & Support-Wissensdatenbanken auf Türkisch: MT + Human-in-the-Loop, aber richtig

Wer technische Dokumentation skaliert, landet früher oder später bei der Frage: Wie bringen wir hunderte, manchmal tausende Seiten verlässlich ins Türkische, ohne Monate zu verlieren oder Qualitätsprobleme zu provozieren. Die kurze Antwort ist: Machine Translation (MT) plus Human-in-the-Loop durch die Arbeit türkischer Übersetzer, vor allem im Post-Editing-Bereich. Die lange Antwort besteht aus ein paar handfesten Architektur-Entscheidungen, die man besser gleich trifft – sonst zahlt man später Zins und Zinseszins.

1) Warum Türkisch besondere Aufmerksamkeit braucht

Türkisch ist agglutinierend. Wörter werden, salopp gesagt, zu Ketten. Das bricht Umbrüche auf schmalen Layouts, treibt die Silbentrennung in die Ecke, und verhagelt bisweilen die Suche. Dazu kommt die berühmte i/İ-Falle: Das punktlose „ı“ (klein) und das große „İ“ (mit Punkt) machen aus harmlosen toLowerCase()-Aufrufen auf einmal einen Fehlerlieferanten. In JavaScript gehört hier toLocaleLowerCase(‘tr-TR’) in die Toolbox, in .NET die CultureInfo(“tr-TR”), in SQL und Suchindizes entsprechende Collations. Klingt klein, ist es nicht.

Wer das linguistische „Warum“ genauer verstehen will, findet bei der LMU München saubere Einstiege in Sprachsystematik und Typologie. Das hilft, technische Symptome nicht nur zu flicken, sondern zu entschärfen.

2) Content-Audit: Was wirklich übersetzt werden muss

Bevor die Pipeline gebaut wird, eine nüchterne Liste:

• High-Impact: Getting-Started, Troubleshooting, API-Übersichten, Release Notes auf der Startseite des Help-Centers.
• Medium: lange How-to-Serien, Modul-Dokumentationen, tiefere Guides.
• Low-Risk/Long-Tail: archivierte Changelogs, sehr alte Tickets.
• Sensible Daten: Logs, Supportfälle mit PII – gehören nicht unverpackt in Cloud-MT. Pseudonymisieren, filtern, oder schlicht ausnehmen. Ein Blick in die IT-Grundschutz-Empfehlungen des BSI ist hier, ernsthaft, kein Luxus.

Priorisieren Sie nach „Impact × Häufigkeit“. So entstehen Releases, die sofort Wirkung zeigen, ohne das Team zu überlasten.

3) Terminologie & Stil: Das Fundament

Ohne Termbase/Glossar wird jedes MT-Ergebnis inkonsistent. Drei Dinge sind Pflicht:

1. Terminologie-Kanban: Produktnamen, Menüpfade, Fehlermeldungen, Befehle. Definieren, was übersetzt wird – und was bewusst nicht (Code, Variablen, interne Bezeichner).
2. Stilentscheidungen: Höflichkeitsform (meist „siz“), aktive Imperative in Anleitungen („Tıklayın“, „Açın…“), Zahlen-/Datums-Formatierung, Währungen.
3. Sperrlisten: Wörter oder Phrasen, die nie verändert werden dürfen (z. B. Token, API-Keys, Dateiendungen).

Wer hier sauber arbeitet, halbiert die Post-Editing-Zeit häufig schon beim zweiten Sprint.

4) Pipeline-Entwurf: MT → Post-Editing → QA → Publish

Eine robuste Pipeline ist simpel, aber streng:

(a) Pre-Processing

• Platzhalter schützen: {userId}, %s, <code> in Markdown/ReST/DITA als „nicht übersetzbar“ markieren.
• Links stabilisieren: Markdown-Links […] ( … ) nicht „auseinanderziehen“ lassen; bei DITA auf intakte xref achten.
• Segmentierung: Übersetzungs-Segmente an Satzgrenzen, nicht an willkürlichen Umbrüchen.

(b) Machine Translation

• Engine nach Domänenleistung auswählen, nicht nur nach generischen Benchmarks.
• Terminologie-Injection, falls verfügbar, aktivieren; bei fehlender Unterstützung notfalls via Pre-/Post-Rules nachsteuern.

(c) Post-Editing (PE)

• Light PE für Volumentexte: Grammatik, Lesbarkeit, Terminologie, Links prüfen.
• Full PE für sichtbare Flächen: Landing-Docs, transaktionale Mails, Startseiten-Snippets.
• i/İ-Themen systematisch abarbeiten: Überschriften, Slugs, Anker-IDs, Such-Tags.

(d) QA

• Terminologie-Lint (Trefferquote, Blacklist-Verstöße).
• Regex-Checks: Platzhalter unverändert? HTML-Tags geschlossen?
• Link-Checker (intern/extern), Zahlen und Einheiten, Datum.
• AQL-Stichprobe: Bei großen Batches spart das viel Zeit, ohne Qualität zu opfern.

(e) Publish

• Automatisiert ins KMS (Zendesk, Confluence, Git-Docs etc.).
• Feedback-Schleife: Tickets aus dem türkischen Markt als Signal werten, nicht als Störung.

Eine kompakte Visualisierung (Flow-Diagramm) auf der Team-Seite hilft, dass niemand Sonderwege baut.

5) Tooling & Formate

• Quellformate: Markdown, reST, DITA XML, HTML, JSON/YAML, PO/XLIFF.
• Ablage/CI: Git-basiert, PR-Reviews, CI-Jobs für Terminologie-Lint, Link-Check, Broken-Markup.
• Strings: Schlüsselbenennung konsistent halten; keine „freien“ Texte in JSON-Werten ohne Kontext.

Zu den typischen Stolpersteinen habe ich eine kompakte, technische Übersicht samt Vorher/Nachher-Beispielen zusammengestellt – wer Details braucht, findet sie hier: weiterführende Analyse.

6) KPIs: Messen, aber mit Maß

Drei KPI-Blöcke reichen völlig:

• Betrieb: Time-to-Publish, Post-Editing-Minuten je 1.000 Wörter, Kosten je 1.000 Tokens.
• Qualität: Terminologie-Trefferquote, Link-Fehlerquote, Platzhalter-Fehler.
• Effekt: Self-Service-Rate (Anteil gelöster Fälle ohne Ticket), Ticket-Deflection, türkischer CSAT.

Wöchentliches Reporting genügt meistens. Tägliche Dashboards sehen hübsch aus, machen aber selten bessere Texte.

7) Häufige Fehler (und die Gegenmittel)

• PII in MT: vorab filtern oder pseudonymisieren. Sonst hat man später ganz andere Gespräche.
• Terminologie-Drift: ohne Owner verwässert der Stil. Ein:e Verantwortliche:r, klare Freigabewege.
• Harte Zeilenumbrüche in Aufzählungen → zerstören türkische Wortformen.
• Case-Mapping: toLowerCase() ohne Locale – bitte nicht mehr 2025.

Noch ein praktischer Hinweis: Screenshots in Docs sind schön, aber nur wenn Buttons/Labels in der Sprache der Seite sind. Sonst fällt die Conversion, erfahrungsgemäß deutlich.

8) Mini-Beispiele aus der Werkstatt

Platzhalter-Schutz (Regex-Idee)

• Find: (\{[^}]+\})
• Keep as is: Segment markieren, Engine darf nicht „übersetzen“.

Imperativ

• Deutsch: „Bitte klicken Sie auf Verbindungen testen und warten Sie…“
• Türkisch (sauber, knapp): „Bağlantıları test et’e tıklayın ve …“

Slug/Suche

• IDs, Slugs und Tags konsequent mit tr-TR-Regeln erzeugen und testen, nicht „irgendwie“. Das erspart sehr viel Frust.

9) Betriebsmodell, Rollen, SLAs

• Rollen: Tech Writer (Owner), Terminologie-Owner, PE-Editor, QA-Lead.
• SLAs: Hotfix 24–48 h, Batch wöchentlich, Langtexte im Zwei-Wochen-Rhythmus.
• Governance: Terminologie-Änderungen im monatlichen Review; Änderungen dokumentieren, nicht mündlich „nebenbei“.

10) Startplan in vier Wochen

1. Woche 1: Glossar aufsetzen, Styleguide minimal, 20–30 High-Impact-Artikel auswählen.
2. Woche 2: Pre-Processing-Regeln, MT-Tests mit Glossar, Light-PE definieren.
3. Woche 3: QA-Jobs (Terminologie-Lint, Links, Platzhalter), Pilot-Release.
4. Woche 4: KPI-Review, Term-Nachschärfung, Rollout-Plan für den Long-Tail.

Wer zusätzlich eine professionelle Schnittstelle für juristisch belastbare Dokumente braucht (z. B. AGB, Zertifikate, Bewerbungsunterlagen), verlinkt im Kontext dezent auf einen Fachübersetzer-Pool – dort, wo es fachlich Sinn macht.

11) Schlussbemerkung

Das Entscheidende ist nicht „MT ja/nein“, sondern Prozessdisziplin: Terminologie festigen, Platzhalter schützen, Locale-Regeln ernst nehmen, und eine klare QA-Schicht davor setzen, bevor etwas live geht. Dann funktioniert das, auch bei starkem Content-Zuwachs, ohne dass das Team ausbrennt. Und ja, ein paar Eigenheiten des Türkischen muss man akzeptieren, sonst kämpft man gegen die Sprache statt mit ihr zu arbeiten. Für tiefere Hintergründe hilft die fachliche Literatur (s. o. LMU) und für Security-Rahmenwerke das BSI. Mehr braucht es am Anfang nicht, außer den Entschluss, es jetzt wirklich sauber aufzusetzen.