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