Over the last couple of years IWMS vendors have extended their customer horizon from local region / country specific customers to the large Fortune 500 multinationals. When IWMS vendors are crossing borders, they have to face all kinds of internationalization (i18n) challenges. In this week’s post one of the most common I18n challenges of IWMS will be discussed; multi-language.
Business Challenge
Although (Business) English is the most common language in the world of IWMS vendors, other languages need to be supported by the IWMS as well when the vendors extend their reach outside the United States.
User Acceptance
If we take a look at the North American continent already three of the world’s dominant languages are present. (English, Spanish and French). These languages need to be supported by the IWMS system.
IWMS/CAFM systems are dominantly used by local employees within a particular language zone. For instance local employees use the Conference Room Booking module of the IWMS only for their building. If this building is located in Quebec most users probably speak French. If this building is located in San Diego there is good chance that the IWMS will be reqiured and used in Spanish. Business English therefore will not be accepted everywhere even in North America.
Legislation
Besides user acceptance legislation could also be causing problems. In some European countries (such as Germany) legislation obliges vendors to provide both the application as well as the training material in German without exception.
The business challenge for IWMS vendors is obviously to provide this language support to their global customers. This can be extremely difficult and time consuming for IWMS vendors, however unavoidable.
Character Sets
To raise the ante; When IWMS vendors follow their customers to regional language zones with different character sets such as Cyrillic, Arabic, Chinese, Japanese, Korean, Russian, etc. additional investments in language support will inevitably be required. The global marketplace encourages IWMS vendors to be creative with their supported languages when they want to service a global customer base.
Iwmsnews provides you with 9 guidelines for Multi-language below.
9 Guidelines for Multi-language
As stated above multi-language is a significant business challenge for IWMS vendors. However, here are some guidelines for Multi-language support.
1. Language settings at the user level
If a user in a French language area accesses the system all field labels, tabs, bars, etc. need to be in his language. Obviously this is not the case for data in the database. If the name of the building is in English both the French and English user will see the English name of the building. (Although some systems also provide data translation it’s not preferable)
2. Language selection by end user
Through a portal or interface the end user should be able to change his / her preferred language settings.
3. Predefined lists per language
For each user lists with predefined items need to be in their own language e.g. priorities for solving maintenance requests. When an end user switches between languages these predefined lists should be updated by the system as well.
4. Separate language documents for each language
The most comprehensive methodology both for end users and IWMS vendors is to create separate language documentsfor each language. Modifications therefore do not affect all other languages which is a benefit considering guideline 5.
5. Search and Replace
IWMS Vendors should provide documents (such as csv, html, or doc.) that can also be edited manually. In this case modifications to global terminology can be done by using ‘search and replace’ functionalities of native applications.
6. Updating through the user interface
End users (system administrators) should be able to update all field labels, tabs, bars, etc. through the administration interface. In this way the organization creates its own language which is the business language of the organization.
7. Exportable user defined languages and data
Once you start working with the systems language you’ll start creating a comprehensive business dictionary for your own organization. In some cases you want to use this for other applications as well. Therefore exportable (parts) of language documents could be extremely helpful.
8. Language backup
The language needs to be backed up frequently and stored also outside the application. When the IWMS database crashes you still posses the language.
9. Old vs New Release Language
In every new release of the software new fields, labels, tabs, bars, etc., are provided by the vendor. It needs no explanation that the old language cannot be entirely overwritten by the new release language.
I’d love to hear which guidelines for multi language you can come up with. Please use the comment form below this post.
i18n, Internationalization
Leave a comment