Localization Improvements

As MidPoint was born in the Europe, it naturally supports localization. Otherwise midPoint wouldn’t be able to survive in the European melting pot of languages and cultures. However, complete localization of any software package is a surprisingly complex task.

MidPoint versions 3.x and 4.0 are well suited for a single-language environments. Which means you can choose any supported language that you want and midPoint will talk to you in that language. But when it comes to supporting several languages at the same time, there are still limitations. Those limitations are given by the localization of the content of midPoint.

Localization of midPoint user interface is quite easy. There are well-known and proved techniques, such as using localization catalogs. This requires a huge amount of work to maintain the localizations - big thanks to all midPoint translators is in order here. But otherwise this localization approach works like a charm. The problem is a localization of data. Firstly the data are created during deployment. Therefore the translator cannot translate them as they simply do not know them. Secondly, the data may be presented in many languages at once. Which makes operations such as searching and sorting very difficult.

MidPoint 4.0 have some mechanism to deal with data localization, such as PolyString. PolyString was part of midPoint design almost from the beginning. The developers are based in Europe and speaks an obscure native language, therefore it is quite natural that the thoughts about localization played a part in midPoint design. The PolyString was quite simple at the beginning and it got improved in midPoint 4.0. But there is still a long way to go.

But even if PolyString supports full localization, there is still a question how to store (or index) the data in the database. There are some ideas, however those needs to be explored and prototyped to make sure that functionality and performance is acceptable.