„‚Internationalisierung‘ eines WMS bedeutet, das Design der Software so zu bauen, dass später leicht eine ‚Lokalisierung‘ durchgeführt werden kann“, erläutert Wolfgang Gilbert vom Intralogistik-Softwarespezialisten Dr. Thomas und Partner (TUP) aus Stutensee bei Karlsruhe. „Die ‚Lokalisierung‘ ist die eigentliche Übersetzung, und daran hängen auch Datumsformate, Währungen und Sortierregeln.“ Im Japanischen oder Arabischen wird zum Beispiel in einer anderen Richtung geschrieben als in den europäischen Sprachen. Internationalisierung ist die Voraussetzung dafür: „Das heißt, eine Software von vornherein so zu schreiben, dass eine Lokalisierung ohne zusätzliche tiefe Eingriffe möglich wird.“

Ziel von Internationalisierung und Lokalisierung ist immer, dass Übersetzungen gepflegt und angezeigt werden können. Dabei geht es einerseits um Systemmeldungen in der Anwendung und andererseits um Anwendungsdaten aus der Intralogistik. „Die Sprachanpassung der Software ist effizienter und schneller, als den Mitarbeitern den Umgang mit einer Software in einer fremden Sprache beizubringen.“ Ein WMS könne immerhin bis zu 100 oder 150 Dialoge haben, hebt Gilbert hervor. „Mitarbeiter in Dialogen in einer fremden Sprache zu schulen ist sehr schwierig.“

Mit der Lokalisierung verringert sich auch die Fehlerquote: Die Mitarbeiter können die Dialoge in ihrer Landessprache lesen, und logistische Begriffe werden so erklärt, wie es in ihrer Sprache üblich ist. Internationalisierung und Lokalisierung seien nicht kostenlos, räumt Gilbert ein, sagt aber auch: „Das zahlt sich relativ schnell aus, wenn innerhalb des Lagers Kollegen mit unterschiedlichen Sprachen arbeiten.“

Keine Rückkehr zu „Los“ nötig

Als Beispiel für eine zweisprachige Lokalisierung nennt Gilbert ein Projekt in der Slowakei. Während die meisten Mitarbeiter mit ihren Handterminals (Mobile Datenerfassungsgeräte/MDE) in slowakischer Sprache arbeiten, sind die Vorgesetzten überwiegend ortsfremd und nutzen als gemeinsame Sprache Englisch. „Wenn die Lagermitarbeiter ein Problem haben und ihr Vorgesetzter spricht nur Englisch, kann er ‚on the fly‘ am MDE auf die englische Übersetzung umschalten.“

Das sei übrigens eine der großen Herausforderungen gewesen, erläutert Gilbert. In vielen Anwendungen könne nicht einfach am jeweils kritischen Punkt innerhalb eines Dialoges auf eine andere Sprache umgeschaltet werden. Vielmehr könne der Nutzer die Spracheinstellung nur am Startpunkt eines Dialoges ändern und müsse dann die gesamte Situation in der anderen Sprache bis zum kritischen Punkt erneut nachspielen. „Ich habe also an jedem Punkt die Möglichkeit, mir über den Sprachwahl-Selektor die Meldung in dieser oder jener Sprache anzeigen zu lassen.“ Damit für die Lokalisierung nicht immer die Software selbst angefasst werden muss, ist das System so ausgelegt, dass die Texte über eine gesonderte Schnittstelle direkt von einem Übersetzungsbüro gepflegt werden können. Zusätzlich kann der Projektpartner über die webbasierte Anbindung „Mojito“ Texte direkt selbst pflegen, was vor allem bei komplexen Produkten ein wichtiges Feature ist, da so die lokalen Anwender selbst übersetzen können.

Software ist nie „fertig“ – und die Sprachanpassung auch nicht

Unabhängig davon verändert sich WMS-Software ständig. Intralogistische Prozesse werden umgestellt, neue Anforderungen kommen hinzu, manche fallen weg. Auch das Aktualisieren der Sprachanpassung muss also mit bedacht werden. „Wir unterscheiden grundsätzlich zwischen den statischen Meldungen einerseits, die in der Versionsverwaltung mit ihren Übersetzungen berücksichtigt werden müssen, wenn die Software wächst, und andererseits den Anwendungsdaten selbst.“ Die Anwendungsdaten können Artikelstammtexte sein oder andere Stammtexte.

Der Unterschied ist die Lebenszyklus-Dauer: Stammtexte können eventuell auch einen Langzeitcharakter haben. Damit lohnt es sich, diese Texte in der Datenbank zu übersetzen. In der Datenbank gibt es daher keine Versionsverwaltung, da nur Übersetzungen für statische Daten hinterlegt werden.

Hingegen müssen Dialoge in der Versionsverwaltung berücksichtigt werden – bis hin zum sprachspezifischen OK-Button. MDE-Anwendung und Zentralrechner mit dem Dialogsystem laufen parallel. Dadurch hat TUP es in der Hand, in welchen Zyklen die Software und damit eventuell auch Texte in der Anwendung aktualisiert werden.

Nicht jeder Nutzer benötigt alle Sprachen

Während für das sichere und fehlerfreie Arbeiten im Lager die Benutzeroberfläche in der Landessprache essenziell ist, reicht auf den anderen Ebenen eine Standardsprache – im Ausland meistens Englisch. Deswegen hat TUP als Lehre aus einem Auslandsprojekt ein dreistufiges Konzept bei der Lokalisierung eingeführt. „Die Root-Texte stammen direkt vom Entwickler und sind in der Regel auf Deutsch“, erläutert Gilbert. „Auf dem Level darüber kommt eine Standardsprache – meistens Englisch – und erst auf dem dritten Level die Landessprache der Mitarbeiter.“ Frontend und Backend müssen zusammenpassen, betont er.

Wichtig ist eine Fallback-Strategie: Wenn ein Text nicht in der Landessprache gepflegt ist, wird als Rückfallebene der Text in der Standardsprache angezeigt, damit der Nutzer überhaupt etwas sieht. Falls der Text auch in der Standardsprache nicht vorhanden ist, sieht er die Root-Sprache vom Entwickler, also in der Regel Deutsch.

Eine besondere Herausforderung ist laut Gilbert zudem die Druckausgabe von Texten in verschiedenen Sprachen. Zum Beispiel ist ein englischsprachiger Text bei gleichem Inhalt meistens ein Fünftel bis ein Drittel kürzer als sein deutsches Äquivalent. Deswegen legt TUP sprachspezifische Layouts von Etiketten an. „Zum Glück entsprechen wenigstens die Barcodes internationalen Standards“, sagtGilbert. (ck)