If warehouse management systems (WMS) are to be used in many countries and by employees with different native languages, language adaptation must be taken into account during programming.
“Internationalizing a WMS means building the design of the software in such a way that localization can easily be performed later,” explains software specialist for intralogistics Wolfgang Gilbert. “Localization is the actual translation, and date formats, currencies and sorting rules also depend on it.” In Chinese or Arabic, for example, writing is done in a different direction than in European languages. Internationalization is the prerequisite for this: “That means writing software from the outset in such a way that localization is possible without additional in-depth modifications.”
A good, maintainable localization is a competitive advantage
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.
Internationalization and localization aren’t free, Gilbert acknowledges, but also says, “It pays off relatively quickly if you have co-workers with different languages working within a warehouse.”
As an example of bilingual localization, Gilbert cites the logistics center of EF Parts & Logistic Service s.r.o., an Emil Frey Group company, in Bratislava. While most employees work in Slovak with their handheld terminals (mobile data entry devices/MDE), supervisors are mostly non-local and use a common language of English. “If warehouse employees have a problem and their supervisor only speaks English, they can switch to the English translation ‘on the fly’ on the MDE.”
That, by the way, was one of the big challenges, Gilbert explains. In many applications, it is not possible to simply switch to another language at a critical point within a dialog. Rather, the user can only change the language setting at the starting point of a dialog and then has to replay the entire situation in the other language up to the crucial point. “So with our solution, at each point I have the option of using the language selector to display the message in this or that language.”
To avoid always having to touch the software itself for localization, the system is designed so that texts can be maintained directly by a translation agency via a separate interface. In addition, the project partner can maintain texts directly themselves via the web-based connection ‘Mojito’, which is an important feature, especially for complex products, as it allows local users to translate themselves.
What is static and what is not is a deciding factor for the integration of localization into the software structure
Regardless of this, WMS software is constantly changing. Intralogistics processes are reorganized, new requirements are added, and some are dropped. Updating the language adaptation must therefore also be considered. “We basically distinguish between the static content on the one hand, which has to be taken into account in version management with its translations as the software grows, and the application data itself on the other.” The application data can be article master texts or other master texts.
The difference is the life cycle duration: master texts may possibly have a long-term character. This makes it worthwhile to translate these texts in a database. Therefore, there is no version management in the database, because only translations for static data are stored.
On the other hand, dialogs must be taken into account in version management – right down to the language-specific OK button. The MDE application and the central computer with the dialog system run in parallel. This means that TUP has control over the cycles in which the software, and thus possibly also texts in the application, are updated.
Fallbacks and an agreed upon standard language as a safety net for localizations
While the user interface in the local language is essential for safe and error-free work in the warehouse, a standard language – usually English- is sufficient at all other levels. That’s why, as a lesson learned from a project abroad, TUP has introduced a three-stage concept in localization. “The root texts come directly from the developer and are usually in German,” Gilbert explains. “At the level above that comes a standard language – usually English – and only at the third level the national language of the employees.” The frontend and backend have to fit together, he emphasizes.
A fallback strategy is important: If a text is not maintained in the local language, the text is displayed in the default language as a fallback layer so that the user is able to see something in the first place. If the text is not available in the default language either, s/he sees the root language from the developer, which is usually German.
Incidentally, the print output of texts in different languages is a particular challenge. For example, an English text with the same content is usually one fifth to one third shorter than its German equivalent. That’s why TUP creates language-specific layouts for labels. “Fortunately, at least the barcodes conform to international standards,” Gilbert says with a grin.
Summary
- The software must be designed so that localization is possible without additional in-depth modifications.
- Translations must be maintained and can be displayed easily.
- Training employees in dialogs in a foreign language is always riskier than providing appropriate localization.
- A good, tested localization reduces the error quota, the biggest enemy in intralogistics.
- At any point, it must be possible to switch to a different language.
- Users must be able to maintain the translations themselves.
- At the system level, a separation between master texts and system texts is important: master texts have a long lifetime and rarely or never change. System texts can evolve with each software version.
- There must always be a fallback to an agreed upon standard language.