Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow

Subject: Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2011-04-15 13:56:59

On 6/4/2011 23:29, Chad Nelson wrote:
> The formal review of the Boost.Locale library by Artyom Beilis starts
> tomorrow, April 7th, and is scheduled to last through April 16th.
>

> Please explicitly state in your review whether the library should be
> accepted.

Yes. (But I'm not quite sure if the format issue below might warrant a 
conditional Yes)

>      - What is your evaluation of the design?

I generally like it.

I particularly like that it integrates nicely with the std facilities 
(esp. the use of std::string), and it integrates nicely with de-facto 
standard tools for localization and translation. (gettext)

As far as I recall from earlier discussions it would be possible to add 
a backend to be able to use qt's translation files, too. This would be 
great, because it would then be possible to use the same toolchain 
(String extraction and Translation tools) for Application backend code 
when one uses qt for the Application GUI. (Even if not the QT Linguist 
tool is highly sophisticated, so being able to use it would be a great boon)

I wouldn't require such a backend for inclusion, but if/when such a
backend gets written I would like it to be included.

Some criticisms:

* it would be nice if boost::locale::format would also understand normal 
boost::format messages, or a compatible wrapper like 
boost::locale::compat::format that did the right thing.
I think this is important! It would be very unfortunate to have two 
slightly incompatible facilities.

* it would be nice if boost::locale::date_time and boost::date_time 
interacted nicely, or ideally could be merged

* No boundary analysis in non ICU backends. it would be nice if at least 
simple cases (only single codepoint chars) would work correctly.

>      - What is your evaluation of the implementation?

I have only had a brief look, it looks clean enough.

>      - What is your evaluation of the documentation?

First of all I like the layout, it looks nice fresh and modern, and 
individual functions are easy to spot, something which I often miss in
normal boost docu.
But as others have noticed it is a bit hard to navigate, especially in 
the tutorial section. (This might be a problem in doxygen)

One thing I miss is a more throughout documentation of the toolchain 
needed to extract strings, translate them, ... At least an example for 
each major platform with all the needed programms. Bonus Points for 
build system (bjam and CMake) integration.

Some things are not quite clear

* is there a native program to extract translation strings for each 
major platform? (Win-Mac-Linux)?

* how do locale::format and locale::translate interact? will a string 
using format get translated? can I use all of formats niceness in translate?

* some examples on what exactly the limitations of non ICU backends are. 
Something along the lines of if you do this on string x the result is y 
instead of z as it would be with ICU.

As always when commenting on documentation I would like more How-to and 
walk-through examples, especially in the reference section. (somewhat 
like the qt docu which has a nice minimal code sniplett for each 
function, which shows how the function is used to achive something)

>      - What is your evaluation of the potential usefulness of the
>        library?

Very useful. I consider a library that treats the localization as a 
prime candidate for boost and ultimately for standardization.

I consider easy and central localization handling to be important 
because mistakes and oversights in this area lead to subtle and annoying 
user-visible bugs, which are nearly impossible to test automatically.
It is also a topic which is almost never a central concern of any 
application (especially during initial development), and still needs to 
be dealt with in almost all code layers, so a simple standardized API 
which hides the almost insurmountable subtleties and complexities from 
the programmer is IMO essential.

>      - Did you try to use the library?  With what compiler?  Did you
>        have any problems?

Not yet.

>      - How much effort did you put into your evaluation? A glance? A
>        quick reading? In-depth study?

Throughout reading of the documentation, quick look at the code.
If I have a bit of time later I will do a test run, and amend that info.

>      - Are you knowledgeable about the problem domain?

Moderately so. I used Qt's localization an internationalization services 
for a moderately sized application and a companion framework, and am 
currently designing a application framework where I do not want to use 
Qt, at least not for the lower code layers and inter module 
communication, and need something suitable.

Regards, and keep up the good work

Fabio