Translate GETTEXT might be better in a separate library to increase degrees of freedom and reduce coupling.

message translation is generally integrated part of localization, so I don't see a reason to separate it. Also, loading gettext dictionaries require locale information that only boost.locale provides.

--- What is your evaluation of the implementation?

The wrapper/backend strategy provides immediate benefit while leaving the door open to progressive reimplementation.

Since it is a wrapper, could PARTS of it be implemented as a header only?

Several points: - It is not "just a wrapper" it is a wrapper over several APIs: - ICU - POSIX - Win32 API - std::locale API - When you deal with locale facets you have to have a unique object std::locale::id per facet and when working with DLL platform it means that you have to put it into DLL so it would be unique for all other dlls. So there is no way and no really a reason to do this. - It is important for localization library to be lightweight in terms of compilation. Because it is likely going to be used in many parts of code. So using light headers and heavy sources has important strategic impact on adopting this library.

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

This library is potentially *extremely* useful because it LEVERAGES an important chunk of standard C++ that is sadly underutilised merely due to a few design and implementation flaws.

This library has potential something of the order of Boost.FileSystem.

This is a VERY strategic library and any shortcomings will be resolved with time.

I'm glad to hear.

--- Do you think the library should be accepted as a Boost library?

YES - It is relatively small but has a massive effect. It has a very low cost/benefit ratio since it leverages long standing classic C++ locale design/skills.

Thanks, for the review and the vote. Artyom