Re: [boost] [Boost.Locale] Upcoming Boost.Locale version

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

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.