By default, Boost.Locale uses ICU for all localization and text manipulation tasks. This is the most powerful library available, but sometimes we don't need the full power of this library or we want to reduce dependencies from third-party libraries, and ICU is by no means a small library.
Boost.Locale provides an option to use non-ICU based localization backends. Although usually less powerful, these often provide all you need: message formatting, currency, date, time, number formatting, basic collation and case manipulation. They are implemented using the standard OS API or a C or C++ library.
There are situations when using non-ICU based localization is appropriate:
All of the alternate backends have these limitations:
winapibackend, is limited to a single level, similar to what is done by
This localization backend is based on the standard C++ library.
It is supported on all platforms, but is only actually useful on platforms where the standard library supports locales besides "C" and "POSIX": on Linux with GCC or Intel compilers, and under the MSVC compiler.
It works around some common standard library bugs like invalid UTF-8 generation for numeric formatting, and it gives otherwise-absent POSIX locales names and UTF-8 support under MSVC.
It is very useful when the compiler and the library actually give fine localization support, like GCC under Linux or MSVC under Windows.
This backend is based on the latest POSIX 2008 standards, and uses POSIX api functions like
strftime_l etc. It is available on the Linux and Mac OS X platforms.
It gives you simple and ready-made localization support, most notably under Mac OS X where GCC's
libstdc++ does not support locales.
The Win32API-based localization backend provides decent UTF-8/UTF-16 locale support. It is based on Windows API functions like
GetDateFormatW etc and provides good localization support even on the MinGW and Cygwin platforms, which normally have problems with this.
|Non UTF-8 encodings||Yes||Yes||No||Yes|
|Date/Time Formatting/Parsing||Yes||Formatting Only||Formatting Only||Formatting Only|
|Monetary Formatting/Parsing||Yes||Formatting Only||Formatting Only||Yes|
|Numbers as Percent, Spelled Out||Yes||No||No||No|
|Collation||Full||Linux - 1 level|
Mac OS X - broken
|3 levels||1 level|
|Calendar||Yes||Gregorian Only||Gregorian Only||Gregorian Only|
|Unicode Normalization||Yes||No||Vista and above||No|
|OS Support||Any||Linux, Mac OS X||Windows, Cygwin||Any|
|Useful on||Any Platform||Linux and Mac OS X||Windows/MinGW/Cygwin||Linux with GCC or Intel|
Windows with MSVC
Accessing a localization backend is done via the boost::locale::localization_backend_manager class.
You can create your own boost::locale::localization_backend_manager by starting with a global backend via the boost::locale::localization_backend_manager::global static member function and modifying it.
localization_backend_manager my = localization_backend_manager::global(); // Get global backend my.select("std"); // select std backend as default generator gen(my); // create a generator that uses this backend. localization_backend_manager::global(my); // set this backend globally generator gen2(); // now this one would use the new global backend.
You can also create a mixture of several backends, using for example
icu for one kind of operation and
std for all others:
localization_backend_manager my = localization_backend_manager::global(); // Get global backend my.select("std"); // select std backend as default for all categories my.select("icu",boundary_facet); // select icu backend for boundary analysis (since it is not supported by \c std)