Using Localization Backends

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.

When to use non-ICU backends

There are situations when using non-ICU based localization is appropriate:

• Embedded systems, where the ICU library is very hefty.
• Applications where only basic features like message, date, and time formatting and basic collation are required, and using a third-party library like ICU would be too complicated.
• Performance. ICU is a very powerful library, but it is generally slower than the standard library. Sometimes it's better to use a simpler but faster localization backend.

Non-ICU Backends

All of the alternate backends have these limitations:

• Only the Gregorian calendar is supported and it is based on capabilites of mktime functionality (including dates range)
• No boundary analysis.
• Case handling is very simple and based on single codepoint conversions, though they still handle UTF-8 better than the standard library.
• Time zone specification is very limited: either local time or a time zone in the format "GMT+HH:MM".
• No percent formatting, no spellout or ordinal number formatting.
• Collation, with exception of the winapi backend, is limited to a single level, similar to what is done by strcoll.

std - The standard C++ library backend

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.

posix - POSIX 2008 C library

This backend is based on the latest POSIX 2008 standards, and uses POSIX api functions like newlocale, freelocale, 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.

Note

The POSIX backend only supports UTF-8, single-byte, and double-byte encodings.

winapi - Win32 API.

The Win32API-based localization backend provides decent UTF-8/UTF-16 locale support. It is based on Windows API functions like GetLocaleInfoW, LCMapStringW, GetDateFormatW etc and provides good localization support even on the MinGW and Cygwin platforms, which normally have problems with this.

Note

• If you using GCC compiler under Windows you need GCC-4.x series to use it, GCC-3.4 is not supported
• Only UTF-8 as narrow locale encoding and UTF-16 as wide encoding are supported.

Supported Features

Backend	icu	posix	winapi	std
Message Formatting	Yes	Yes	Yes	Yes
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
Number Formatting/Parsing	Yes	Yes	Yes	Yes
Numbers as Percent, Spelled Out	Yes	No	No	No
Case Manipulation	Yes	Basic	Basic	Basic
Collation	Full	Linux - 1 level Mac OS X - broken	3 levels	1 level
Calendar	Yes	Gregorian Only	Gregorian Only	Gregorian Only
Boundary Analysis	Yes	No	No	No
Unicode Normalization	Yes	No	Vista and above	No
C++0x characters	Yes	No	No	Yes
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

Using Localization Backends

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.

For example:

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)