#work@dvinci – Software-Entwicklung: Wie implementieren wir neue Sprachen?

Im September 2020 haben wir 200 Sprints gefeiert. Wir möchten Einblick in die Softwareentwicklung bei d.vinci geben, unsere agile Arbeitsweise nach Scrum vorstellen und erzählen, warum wir Dinge tun, wie wir sie tun.

Zusammen mit unserem Übersetzungsmanager Ali werfen wir einen Blick auf die Entwicklung einer neuen Sprache für die d.vinci Systeme auf die damit einhergehenden Herausforderungen und unsere Lösungsansätze in d.vinci Software-Produkten.

Wie wird Englisch in d.vinci-Systemen hinterlegt?

Die d.vinci Systeme werden auf Englisch entwickelt. Damit meinen wir nicht die genutzten Technologien, sondern die Ausgangssprache für unsere Software-Oberfläche. Wenn wir also einen neuen Software-Button einführen, suchen wir zunächst ein passendes Englisches Wort. Erst danach wird daraus ein deutsches Wort abgeleitet. So gesehen ist Deutsch also nur eine unserer derzeit 14 Sprachoptionen, neben Bulgarisch, Estnisch, Französisch, Italienisch, Niederländisch, Polnisch, Brasilianisch-Portugiesisch, Rumänisch, Russisch, Slowakisch, Slowenisch, Spanisch und Ungarisch. Wir haben derzeit drei Systeme und ein viertes in der Mache. Wir haben mit dem Bewerbermanagement angefangen, später kam das Onboarding dazu. Im Zuge der Anpassungen für eine gute Interaktivität dieser beiden haben wir entschieden, grundlegende gemeinsame Funktionalitäten aus beiden Produkten zu extrahieren. So finden sich Benutzerverwaltung, Rechtemanagement und Grundeinstellungen mittlerweile in einer eigenen Software, der sogenannten Plattform. Die Plattform ist aus Marketingsicht kein eigenes Verkaufsprodukt und wird sowohl mit dem Bewerbermanagement, als auch mit dem Onboarding mitausgeliefert. Aus technischer Sicht ist sie aber sehr wohl zu unterscheiden und verfügt über eine eigene Terminologie, so wie auch die anderen beiden Produkte eigene Terminologien haben.

Aus historischen Gründen werden aber nicht überall dieselben Technologien verwendet. Das Bewerbermanagement ist wesentlich älter als Onboarding und Plattform. Zukünftige Produkte werden ebenfalls mit aktuellen Technologien umgesetzt, die anders bei den bestehenden Produkten sein kann.

Grundsätzlich arbeiten unsere Softwares folgendermaßen:

• Eine Zeichenkette (Engl. „String“) kann ein Wort, eine Phrase oder ein Satz, oder ein ganzer Text sein. Jeder String für die Benennung von Elementen der Benutzeroberfläche hat einen Übersetzungsschlüssel (Englisch „Key“). An den Stellen im Code, an denen ein bestimmter Key hinterlegt ist, erscheint in der Benutzeroberfläche die jeweilige Übersetzung in der aktiven Sprache.
• Im Bewerbermanagement sind Keys und Englische Strings identisch. Das heißt, die Englische Ausgangsterminologie ist im Software-Quellcode selbst hinterlegt. Derselbe String kommt also an vielen Stellen des Codes vor. Vor einem aktuellen Release läuft ein Automatismus über den Quellcode und registriert sämtliche Keys und sammelt sie in einer Liste. Mehrfacheinträge werden ignoriert. Da hier Keys und Englische Strings identisch sind, wird am Ende nicht nur eine Key-Liste, sondern eben auch gleich eine String-Liste für die englische Sprache ausgegeben. Diese englische String-Liste bildet dann die Grundlage für alle weiteren Übersetzungen.
• Im Onboarding und in der Plattform gehen wir anders vor. Hier haben die Keys funktionale Bezeichnungen, z. B. „title.action.Delete“. Daraus geht hervor, dass es sich bei diesem Key um einen Titel (title) bzw. Objektbenennung handelt. Also z. B. der Name eines Buttons, einer Liste, einer Registerkarte oder eines Formularfelds. Auch sehen wir, dass es sich um eine Handlung (action) handelt, also ein Verb. Und schließlich erkennen wir, was das Ziel der mit diesem Key benannten Funktion ist: Delete, also löschen.
  Wie auch beim Bewerbermanagement werden alle Keys aus der Software in eine Key-Liste extrahiert. Der Key-Liste werden dann Englische Strings zugewiesen, die wiederum die Übersetzungsgrundlage für weitere Sprachen sind.

Gerade für das Bewerbermanagement gilt, dass weil die Englischen Strings codeseitig hinterlegt sind in Form von Keys, Umbenennungen und Umformulierungen nicht mal eben nebenbei gemacht werden können. Sie müssen entdeckt, dokumentiert, und gemeldet werden. Danach werden sie gesammelt, eingeplant und im Rahmen eines Entwicklungslaufs (Sprint) umgesetzt. Für die Umsetzung muss ein Entwickler den gesamten Software-Quellcode durchpflügen (Gott sei Dank gibt es eine Suchfunktion!) und die Änderungen an alle betroffenen Stellen umändern.
Und auch das ist nicht immer einfach. Z. B. haben einige Platzhalter für Korrespondenzvorlagen veraltete Benennungen, die wir nur zu gerne bereinigen würden. Jedoch, diese Platzhalter werden in tausenden Korrespondenzvorlagen verteilt über hunderte Kundensysteme verwendet. Es wäre ein leichtes, in unserem Quellcode den Platzhalternamen zu verbessern. Es hätte aber auch zur Folge, dass alle damit verbundenen in Verwendung befindlichen Platzhalter ungültig würden – und dass in allen Kundensystemen alle Korrespondenzvorlagen nach diesem Platzhalter durchsucht und ausgetauscht werden müssten. Diesen Aufwand können weder wir leisten, noch können wir ihn unseren Kunden abverlangen. So bleiben manche historischen Fehler erhalten und wir können nur versuchen, das Beste daraus zu machen.

Auch hier gilt, Fehler sind menschlich und kein System ist perfekt. Auch wir lernen durch unsere Arbeit und vor allem auch mit und an unseren Kunden und sind darum bemüht, die Software in allen Aspekten zu verbessern.

Wie wird übersetzt und welche Herausforderungen gibt es?

Da wir unterschiedliche Terminologie-Quellen haben, besteht immer die Gefahr, dass einheitliche Ausgangsstrings unterschiedlich übersetzt werden. Aus diesem Grund verwenden wir ein kleines aber feines Tool: Ein Translation Memory System, kurz TMS. Dazu laden wir alle String-Listen für unsere Produkte ins TMS hoch und legen für jedes davon eine Liste der verfügbaren Sprachen an.

Wenn eine neue Sprache bestellt wird, beauftragen wir unseren Übersetzungsdienstleister. Dieser findet für uns eine:n geeignete:n Übersetzer:in. Danach legen wir eine neue Sprache für alle unsere String-Listen an. Nach einem kurzen Webinar und einer groben Einführung in die d.vinci Software erhält die Übersetzer:in Zugang zum TMS und kann dort mit den Übersetzungen beginnen.

In der Regel vergehen 4 Wochen von der Beauftragung der Sprache bis zur Auslieferung. Zum einen muss die neue Sprache von der Entwicklung eingeplant und technisch umgesetzt werden. Zum anderen muss der/die Übersetzer:in in das System eingeführt werden und auch einige Kontrollrunden werden durchgeführt, bis die Übersetzungen einsatzbereit sind.

Man könnte es für einfach halten, eine „Vokabelliste“ in eine andere Sprache zu übersetzen – das hat man doch schon in der 5. Klasse gelernt. Aber Übersetzung ist stets mehr, als das Übertragen von einer in die andere Sprache. d.vinci ist ein vielschichtiges System. Job Opening (Ausschreibung), Job Publication (Veröffentlichung), Job Advertisement (Stellenanzeige) – es ist gar nicht so leicht für die Übersetzer:innen, bei all den ähnlichen Begriffen auch differenzierte Benennungen zu finden und diese durchgängig anzuwenden. Das Verb edit heißt auf Deutsch „bearbeiten“ – oder doch lieber „editieren“? Delete heißt „löschen“ – oder besser „entfernen“? Synonyme bereichern die Sprache und können den Unterschied zwischen einfachen und gehobenen Texten ausmachen. Aber beim Übersetzen von Produktterminologie gelten andere Anforderungen: Unmissverständlich, zielgruppengerecht und konsistent müssen sie sein. Wenn jemand unseren Kundensupport anruft und wir leiten an, die gesuchte Funktion auf der Seite Bewerbungsformular zu finden – die aber als „Bewerberbogen“ angezeigt wird – dann sucht und sucht die Person und wundert sich und beide Parteien fragen sich, warum sie sich nicht einig werden. Es kommt zu Missverständnissen, Fehlkonfigurationen, Frust, Unsicherheit und Zeitverschleiß.

Jedoch, wie immer ist nicht alles ein-zu-eins übersetzbar. Synonyme in der Übersetzung sind schlecht, in der Ausgangsterminologie hingegen eine alltägliche Herausforderung. Submit Application heißt, als Benutzer die Bewerbung manuell zu erfassen. Aber, Submit Application heißt auch, als Bewerber die Bewerbung abzusenden. Auch in solchen Fällen muss sichergestellt werden, dass die gewählten Übersetzungen an allen betroffenen Stellen konsistent angewendet werden.

Und schließlich lässt sich nicht alles problemlos übersetzen, wie oben an einigen Beispielen verdeutlicht wurde. Im Deutschen greifen wir gerne auf Anglizismen zurück. Eine Bewerbung zu parsen ist eben mehr, als sie zu erfassen. Es geht um syntaktische Analyse der betrachteten Texte mit Hilfe automatisierter Technologien und die Zuweisung der ausgelesenen Informationen zu den passenden Feldern. Dafür gibt es kein deutsches Wort, zumindest kein gebräuchliches. Aber nicht jede Sprache verwendet Anglizismen, selbst wenn sie kein eigenes Wort dafür hat. Wie also übersetzt man dann?

Am Ende sind wir sehr auf das Sprachgefühl und Sprachgeschick der Übersetzer:innen angewiesen, mehr als man für die Übersetzung einer „Vokabelliste“ erwarten würde. Ebenso auf ihre Sorgfalt und Achtsamkeit in Bezug auf die kontextuelle Sinnhaftigkeit und Konsistenz der gewählten Übersetzungen. Zumal die Erfahrung gezeigt hat, dass alle Übersetzer:innen auf dieselbe Herausforderung stoßen: d.vinci ist eine vielschichtige und komplexe Spezialisten-Software, die zu bedienen ein großes Maß Expertenwissen und Fachvokabular voraussetzt. Eine:n Übersetzer:in zu finden, die auch noch Hintergrundwisse in Recruiting-Belangen der eigenen Sprache hat, das ist sehr schwierig.

Wie kann die Qualität der Übersetzungen geprüft werden?

Wir bieten verschiedene Sprachen als einen Service für unsere Kunden an, damit d.vinci an allen benötigten Einsatzorten verwendet werden kann, dabei versuchen wir immer, Ihnen jederzeit die bestmögliche Qualität zu gewährleisten. Am Ende findet die Qualitätsprüfung ohnehin bei Ihnen, unseren Kunden, statt.

Viele Fehler wurden bereits gefunden und bereinigt, weil Sie sich bei uns gemeldet und Verbesserungsvorschläge gemacht haben.
Diese nehmen wir sehr gerne an und möchten gerne betonen und alle unsere Kunden dazu ermutigen: Sprechen Sie uns an! Wenn Sie einen Fehler finden oder einen besseren Ausdruck kennen, schicken Sie uns diesen einfach an technische-redaktion@dvinci.de. Fehler sind menschlich und wird es immer geben – aber wir freuen uns über jeden Fehler, den wir korrigieren können 🙂

Wenn Sie weitere Fragen zum Thema haben, melden Sie sich gern bei uns!