Boost logo

Boost :

Subject: Re: [boost] [Boost.Locale] Upcoming Boost.Locale version
From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2010-08-24 10:48:59

>> 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
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at