Sprachregeln erfolgreich einführen
Ein hoher Qualitätsanspruch an die Technische Übersetzung erfordert oft aufwendige Korrekturläufe und häufige Rückfragen. Das treibt den firmeninternen Mehraufwand und den Preis in die Höhe. Mit der Einführung von Sprachregeln verbessern Sie die Technische Übersetzung, senken die Kosten und steigern gleichzeitig die Verständlichkeit Ihrer Dokumentation für die Endkunden. Wie Sie Sprachregeln erfolgreich einführen, lesen Sie hier.
Warum Sprachregeln zu guten Texten führen
In der Technischen Übersetzung sind Formulierungsrichtlinien, Styleguides und Translation Memory schon lange im Einsatz. Sie reduzieren Verständnisfragen, sichern Ihr Corporate Branding und halten die Technische Übersetzung auch über wechselnde Dokumente und Redakteure hinweg durchgängig konsistent.
Um die Kosten für die Technische Übersetzung weiter zu senken, rückt die Qualität des Ausgangstextes stärker ins Blickfeld. Nutzt schon der Quelltext konsequent gleichförmige Formulierungen, können weitere und längere Phrasen ins Translation Memory aufgenommen werden. So spielen die vorhandenen Werkzeuge für die Technische Übersetzung ihre Fähigkeiten voll aus. Das hebt die Qualität, beschleunigt den Übersetzungsprozess und senkt den Preis.
Das Projekt Text-Standardisierung
Damit die Einführung von Sprachregeln nicht zum Selbstzweck wird, sollte dem Projekt eine genaue Recherche und Analyse vorausgehen. Sie zeigt den Bedarf auf und ermöglicht es, den späteren Nutzen für die Technische Übersetzung in konkrete Zahlen zu fassen.
Rücken Sie die Unterstützung Ihrer Technischen Redakteure in den Vordergrund Ihres Projektes. Fassen Sie nicht zu viele Regeln ins Auge. Fünf Regeln, die jedem Redakteur schnell selbstverständlich werden sind weit wertvoller, als fünfzig Regeln auf dem Papier.
Stufe 1 – Recherche und Analyse
Um das Projekt zu starten, geht es zunächst an die Erfassung von Kennzahlen. Hier sind einige nützliche Fragen, die Ihnen weiterhelfen:
– Wie viele Technische Redakteure schreiben an Ihrer Technischen Dokumentation?
– Sind auch die Entwickler oder Ingenieure in die Erstellung eingebunden?
– Für wie viele Zielsprachen benötigen Sie eine Technische Übersetzung?
Sind die Kennzahlen erfasst, sammeln Sie Text-Beispiele in der bestehenden Dokumentation und der jeweiligen Technischen Übersetzung. Erfragen Sie Feedback auch von Ihren Redakteuren und den Dienstleistern für die Technische Übersetzung. Mit diesen Informationen können Sie nun evtl. Mehrkosten und unnötige Risiken der bisherigen Vorgehensweise erkennen. Hierbei handelt es sich zum Beispiel um:
– Mehrfache Übersetzung sehr ähnlicher Textpassagen
– Zeitverlust durch Rückfragen
– Falsche Übersetzungen
– Erhöhtes Haftungsrisiko.
Gesammelte Beispiele und die Kalkulation machen die Problematik damit auch für all diejenigen sichtbar, die nicht täglich mit Sprache umgehen. Diese Vorgehensweise liefert Ihnen die Argumente, um die Vorteile eines Standardisierungs-Projektes gegenüber mitschreibenden Entwicklern und dem Management zu erläutern.
Stufe 2 – Zielsetzung und Zeitplan
Mit den Daten aus der Recherche formulieren Sie die wirtschaftlichen und linguistischen Ziele für das Projekt. Beispielhafte wirtschaftliche Zielsetzungen sind:
– Spezifischer Prozentsatz weniger Rückfragen pro Technischer Übersetzung
– Spezifischer Prozentsatz geringere Übersetzungskosten pro Sprache
– Anzahl Stunden eingesparter Nacharbeit im eigenen Haus.
Beispielhafte linguistische Ziele sind:
– Anteil der wieder verwendbaren Textpassagen erhöhen
– Prüfbarkeit der Texte durch automatisierte Werkzeuge verbessern
– Technische Übersetzung durch automatisierte Werkzeuge unterstützen
– Konsistenz der Texte für den Nutzer bzw. Endkunden erhöhen.
So vorbereitet erstellen Sie einen Projektplan. Planen Sie dabei langfristig und achten Sie darauf, wichtige Schlüsselmitarbeiter nicht zu stark zu belasten. Rechnen Sie für die erfolgreiche Einführung vom Projektstart bis zur vollen Integration der Standardisierung mit etwa sechs Monaten pro Abteilung.
Stufe 3 – Tools und Regeln
In dieser Stufe legen fest, ob Sie Ihre eigenen Sprachregeln für die Technische Übersetzung anhand der gesammelten Beispiele frei formulieren möchten oder ob Sie die passende Regeln aus etablierten Regelkatalogen auswählen. Die Tekom, Gesellschaft für Technische Kommunikation, bietet mit der Leitlinie „Regelbasiertes Schreiben“ einen umfangreichen und bewährten Regelkatalog. Für konkrete Regel-Empfehlungen sprechen Sie auch gerne den Autor an.
Ein anderer Ansatz ist es, zuerst ein Software-Werkzeug auszuwählen, dass die in Stufe 1 erkannten Problematiken erkennt und direkt im Text anzeigt. Jedes Prüfprogramm bringt seinen eigenen Regelsatz mit, der als Anregung genutzt werden, die für Ihren Bedarf wichtigsten Regeln auszuwählen. Automatische Prüfwerkzeuge bieten darüber hinaus die Möglichkeit, eine Vielzahl von Kennzahlen zu erheben, mit der Sie den Erfolg der Standardisierung messbar machen.
Unsere Empfehlung: Nehmen Sie sich nicht zu viele Regeln vor. Bis zu 10 klar definierte Sprachregeln dürfen Sie jedem Autor zumuten, auch wenn Entwickler und Ingenieure an der Technischen Dokumentation mitarbeiten. Vollzeit-Redakteuren dürfen Sie bis zu 20 Regeln auftragen. Wollen Sie weit mehr Regeln einführen, ist eine automatisierte Kontrolle mit einer spezialisierten Software unumgänglich.
Stufe 4 – Einführung und Testphase
Diese Stufe beginnt mit dem schriftlichen Festhalten der zuvor ausgewählten Sprachregeln in einem Redaktionsleitfaden. Damit werden die bestehenden und auch neue Redakteure an die geplanten Satz- und Wortregeln herangeführt. Gliedern Sie jetzt ein eventuelles Software-Prüfwerkzeug in Ihre IT-Landschaft ein.
Danach machen sie die Mitarbeiter, die als Pilotanwender dienen, mit den Regeln und dem neuen Werkzeug vertraut machen. Jetzt beginnt der wichtigste Teil des Projektes. Die Sprachregeln wollen nicht nur intellektuell verstanden sein, sondern müssen in den täglichen Einsatz überführt werden. Jeder Technische Redakteur muss die neuen Satz- und Wortstrukturen in seinen aktiven Schreibprozess übernehmen.
Manchmal stellt sich im ersten praktischen Test heraus, das einzelne Regeln noch einmal angepasst oder leicht überarbeitet werden müssen. Ist dieser erste Probelauf gut überstanden, geht es daran, das Regelwerk und das Prüfwerkzeug auch den weiteren Technischen Redakteuren vorzustellen. Je nach Größe und Verteilung der Arbeitsgruppe kann das durch Dokumentation, Einzelberatung oder Workshops geschehen.
In den ersten Tagen und Wochen mit den neuen Regeln werden Fehler auftreten. Das ist normal und erwartbar. Mit persönlichem Coaching oder einer Telefon-Hotline für Zweifelsfälle helfen Sie den Technischen Redakteuren schnell über die ersten Einsatzhürden hinweg.
Stufe 5 – Einsatz und Erfolgskontrolle
Gerade in den ersten Wochen des Einsatzes ist die Motivation der Technischen Redakteure ausgesprochen wichtig. Ein Gelegenheitsautor wird sich in dieser Zeit über ein intensives Feedback freuen, was er richtig macht und wo er noch etwas ändern muss. Ein Vollzeitredakteur wird möglicherweise eine Software vorziehen, mit der er seine Fehler selbstständig korrigieren kann.
Zu Beginn wurden messbare Ziele besprochen, die Sie schriftlich festgehalten haben. Nach einigen Monaten Einsatz-Praxis ist es an der Zeit, die Zielerreichung zu messen. Wurden die Rückfragen für die Technische Übersetzung wie geplant um 10 % reduziert? Waren es noch weniger Rückrufe? Wie viele Stunden Nacharbeit sind noch angefallen? Wie viele wurden eingespart?
Projekterfolg und Nächste Schritte
Bewerben Sie die erreichten Ziele im Team und im restlichen Unternehmen. Positive Aussagen und Erfolge sind immer gern gesehen und motivieren weitere Abteilungen, es Ihnen mit dem Qualitätsansatz gleich zu tun.
Zeigen Sie die Ersparnisse für die Technische Übersetzung auf und verweisen Sie auf die gesteigerte Qualität der Ausgangsdokumentation. Als nächste Schritte können weitere Abteilungen oder Arten der Dokumentation mit in das Standardisierungskonzept einbezogen werden. Möglicherweise erlauben die gesunkenen Übersetzungskosten jetzt sogar die Expansion in weitere Länder, die bislang aufgrund der Sprachbarriere nicht bearbeitet wurden.