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.