I like to think in terms of [serialized] objects and not strings. Besides having to internationalize images sometimes I need to do the same to arrays of strings or any type of object. In the use case of array of strings, I may in English have a selection or radii ["25 miles", "50 miles", "75 miles" "100 miles", "150 miles", "200 miles"]. However in a different language I may have ["50km", "100km", "150km", "250km"]. Because the unit is different I may more or fewer items in the array. The items in the array may not even be strings but a unit object that has both
runtime scaler and runtime unit.
There is a general approach to solve such issues, even if this is not supported by the library.
You use following:
double factor = atof(dgettext("Distance conversion factor for km","1.0").c_str()); int local_distance = static_cast<int>(metric_distance * factor); std::cout<<format(translate("{1,num} kms","{1,num} kms",local_distance)) % local_distance
That's it.
You just define some translation string and use it as localization reasource. And tanslator translates this factor to ~1.6 and kms to miles according to locale.
The conversion of ["25 miles", "50 miles", "75 miles" "100 miles", "150 miles", "200 miles"] is ["40.2336 km", "80.4672 km", "120.70080000000001 km" "160.9344 km ", "241.40160000000003 km", "321.8688 km"]. Conversion is not an option because an end user would not want to see fractional more less oddball numbers such as 241 or 322. Because of this an end user would be presented with a different array of strings; one that makes more sense in that locale such as ["50km", "100km", "150km", "250km"]. There are a different number of items in the array because of the different length scale factor it wouldn't make any sense to preserve the same number items from the end user's perspective and business requirements can further drive this. As such I need to I18N the array of strings as a whole not each string individually. ICU supports simple integer array but not simple string array. So what support does your library have for the ICU complex types. Remember ICU arrays and tables can contain recursively other ICU arrays and tables. I think both your library and ICU are wonderful but would like some mappings, convenience functions, perhaps in another library that provide the following. simple type integer array => vector<int> or any collection of int complex type array of primitive => vector<primitive or string or any> or any collection of primitives, strings, any(s) complex type table of primitive => map<primitive or string or any> or any associative collection of primitives, strings, any(s) multiple boost ICU serialization archives for more complex types capable of generating reading using the ICU api and other output and input archive for creating the .txt document passed to genrb.exe With such there would be no need for the users of the library to have to keep writing std::ostream &operator<<(std::ostream &out, ... const &d) over and over again for each type especially if the predefined type already have serializers. Originally I had thought of storing a object as a string in one field but I didn't know or understand what ICU complex types are capable of. Consider the following exerpt from the ICU documentation http://userguide.icu-project.org/locale/resources gave an example of a menu translated/serialized as such menu { id { "mainmenu" } items { { id { "file" } name { "&File" } items { { id { "open" } name { "&Open" } } { id { "save" } name { "&Save" } } { id { "exit" } name { "&Exit" } } } } { id { "edit" } name { "&Edit" } items { { id { "copy" } name { "&Copy" } } { id { "cut" } name { "&Cut" } } { id { "paste" } name { "&Paste" } } } } ... } } Now imagine a menu object that was serializable/ translatable and could be retrieved with a single line menu rb.translate<menu>("menu");. In this example a menu in a different locale could have not only different text, but different keyboard handlers and even different number of [sub] menu items. I don't know if this functionality belongs in your library, built on top of your library, or as a better C++ ICU wrapper that what is currently provided by ICU. It is still a need though. Please send me your thoughts or if I need to clarify on anything.