Wenn Lagerverwaltungssysteme (Warehouse-Management-Systeme/WMS) in vielen Ländern und von Mitarbeitern mit unterschiedlicher Muttersprache genutzt werden sollen, muss die Sprachanpassung schon beim Programmieren mitgedacht werden.
„Internationalisierungeines WMS bedeutet, das Design der Software so zu bauen, dass später leicht eine Lokalisierung durchgeführt werden kann“, erläutert Softwarespezialist für Intralogistik Wolfgang Gilbert. „Die Lokalisierung ist die eigentliche Übersetzung, und daran hängen auch Datumsformate, Währungen und Sortierregeln.“ Im Chinesischen 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.“
Eine gute, pflegbare Lokalisierung ist ein Wettbewerbsvorteil
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, der größte Feind in der Intralogistik: 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.“
Als Beispiel für eine zweisprachige Lokalisierung nennt Gilbert das Logistikzentrum der EF Parts & Logistic Service s.r.o., einem Unternehmen der Emil-Frey-Gruppe, in Bratislava. 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 kann nicht einfach am jeweils kritischen Punkt innerhalb eines Dialoges auf eine andere Sprache umgeschaltet werden. Vielmehr kann der Nutzer die Spracheinstellung nur am Startpunkt eines Dialoges ändern und muss dann die gesamte Situation in der anderen Sprache bis zum kritischen Punkt erneut nachspielen. „Bei unserer Lösung habe 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 Anwendern selbst übersetzen können.
Was ist statisch und was nicht ist ein entscheidendes Kriterium für die Integration der Lokalisierung in die Software-Struktur
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 mitgedacht 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.
Fallbacks und eine vereinbarte Standardsprache als Sicherheitsnetz bei Lokalisierungen
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 übrigens 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“, sagt Gilbert und grinst.
Zusammenfassung
- Die Software muss gestaltet sein, dass eine Lokalisierung ohne zusätzliche tiefe Eingriffe möglich ist.
- Übersetzungen müssen gepflegt und ohne Aufwand angezeigt werden können.
- Mitarbeiter in Dialogen in einer fremden Sprache zu schulen ist immer riskanter als eine passende Lokalisierung zu bieten.
- Eine gute, gestete Lokalisierung verringert die Fehlerquote, den größte Feind in der Intralogistik.
- An jedem Punkt muss in eine anderen Sprache gewechselt werden können.
- Anwender müssen die Übersetzungen selbst pflegen können.
- Auf der Systemebene ist eine Trennung zwischen Stammtexten und Systemtexten wichtig: Stammtexte haben eine hohe Lebensdauer und ändern sich selten oder nie. Systemtexte können sich mit jeder Software-Version weiterentwickeln.
- Es muss immer einen Fallback auf eine vereinbarte Standardsprache geben.
Dieser Beitrag wurde auch auf der Seite Technische-Logisitk.net veröffentlicht (Aktives Abonnement benötigt) sowie in der Ausgabe 2019/02 der Fachzeitschrift IT & Production auf Seite 10 veröffentlicht.