Blog
Multiple languages in Next document and process management
Multi-Support Next is used all over the world. For most of our end-users it is important to work with the solution in either their own native language, or at least in the chosen corporate language.
When you work with a Next solution you meet:
- the Next UI (User Interface)
- the solution structure (archives, cabinets, processes etc.) and
- the actual content (Documents, comments, annotations, and data)
User interface
Next is designed to dynamically support global implementations with multiple languages and associated formatting of elements as dates, numbers, and currencies. All elements in the UI (User Interface) are translated into a number of supported languages, and we add new languages as the need arises.
When a Next product is installed, the client selects the preferred language. Multiple languages is available by installing one or more additional language packs on the Next server, and configuring what language each user prefers.
Four Next users accessing the same document in English, German, Danish, and Finish. Click to view larger image.
The use of externalized language packs come with a small performance penalty, but it is a price we gladly accept in order to avoid building and supporting language specific products.
I caution you to consider how introducing multiple UI languages may affect your internal solution training and support setup. All things being equal, introducing additional languages will increase your support and training efforts.
Structure
The elements you use to build the structure in your Next solution are: Archives, Cabinets, Folders, Document types, Users, and User groups. You name these structural elements to match your terminology – e.g. a “Customer” cabinet, an “Invoice” document type, an “Invoice approval” process, and an “Accounting” User group. My example is in English, but in the German subsidiary you may call the same elements: “Kunde”, “Rechnung”, “Rechnung genehmigen” and “Buchhaltung”.
Next does not support creating such structural elements in multiple languages in a single logical archive. Adding support for this feature would complicate configurations dramatically, also for the 99% with no need for this.
Support for multiple variants of structural names would also deteriorate search and retrieval performance dramatically, or alternatively increase the size of the generated search index. Today’s Next applications do not rely on normalized relational databases but on append only databases and search engine technology to provide blasting fast performance. .
I caution you to consider how introducing multiple structural languages may affect your internal solution training and support setup. All things being equal, introducing additional languages will increase your support and training efforts.
You may have compelling reasons to do so anyway, and of course there is a solution for that as well.
If you want some of your users to find invoices in the “Customer/1100” folder, and other user to find the same invoices in the “Kunde/1100” folder, you simply define both cabinet structures, and two automatic filings. This will also allow you to build a separate “filing text string” in each language. You will use permissions to allow English-speaking users to see “Customers” and German-speaking user to see “Kunde”. The overhead in processing and storage space for an extra logical archiving is negligible.
If you want a German and an English project manager to get process instructions in both their native language in a single mixed archive, you simply make two different tasks: “Approving the Project” and “Projekt genehmigen”.
I caution you to be careful when caseworkers start to add comments and annotations to documents in their own language. Consider selecting a corporate language for collaboration.
Content
Next supports Unicode, and is as such capable of handling documents, textual and other content in any language.
Should you choose to mix documents and processes of different languages in a single archive, you should consider the implications. Making meaningful searches across different languages is not trivial. Especially when free text content search is enabled.
The libraries used with Next take care of the fact that the rules for stemming and stop words vary from language to language, but does not eliminate the difficulties in searching across different languages, and the challenges in understanding annotations and comments entered by users in their own language. Note 1: Free text in Next is enable on a project by project basis.
Conclusion
Multi-Support Next has everything you could ever want in language support. Except support for RTL (Right to left languages), in the UI, and that is in the plans as well.
Still there may be scenarios out there, which we have not yet taken into consideration. Scenarios that warrants for adding even more elements to our already elaborate language support. If you know of such scenarios, don’t hesitate to share with me.
Even with Next’s elaborate support for multiple languages I must caution you to consider simplifying your use of if. All things being equal, introducing additional languages will increase your support and training efforts. Maybe it is worth the extra “cost”, but at least consider before just doing it because it’s possible.
Thank you, Danke, Merci, Tak, kiitos, Asante, 谢谢.
