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

Subject: Re: [boost] Fw: [locale] Formal review of Boost.Locale library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-07 09:51:22

Hello,

>
>
> >    - What is your evaluation of the documentation?
> [SNIP]
>
> * The examples are not motivating, and just end up looking complex.
>

Can you be more specific?

>
> * I'd have liked to see examples in more languages, in particular some
>   Asian languages, to comfort me that the library has taken their issues
>   into consideration. If the itch being scratched here is just for a
>   couple of European languages then the library may have design flaws.

Unfortunately I don't know any East-Asian Language, neither Chinese nor Japanese.

So it would be very hard for me to write reasonable sane examples
in these languages.

I know Hebrew, Russian, English, Ukrainian so these languages
are chosen for writing examples and added some other points
like Arabic-Locale numbers and some other things.

However with their East-Asian lingual problems, relevant unit tests
include East-Asian text and I relay heavily on correctness of 3rd part
libraries like ICU.

>
> * The backends page (
> http://cppcms.sourceforge.net/boost_locale/html/using_localization_backends.html
> ) looks interesting, and may be the start of justifying the reason for
> this library to exist.


The biggest difference between using and not using ICU backend
is linking with ICU library which weights about 18 MB on Linux/x86_64.

Timings are really depend on specific cases and not always
closely comparable, sometimes I find ICU faster sometimes
it slower.

I must admit that after recent modifications Boost.Locale's ICU
backend is has comparable performance with other backends
like std or posix.

In may experience when I use Boost.Locale in CppCMS I almost
always may use std or posix backends without particular problems.

Only when I need more advanced features ICU is required part.

> It could be expanded with something more
> concrete: complete examples of doing something useful with different
> backends, with timings and exe sizes we could compare.
>

Actually take a look on this table, and general examples,
almost everything is usable with std or other backends however
the quality and nuances are different for example
whether the number 103 in ar_EG.UTF-8 locale represented
as "103" or as "Ù¡Ù Ù£"

So almost all examples are valid (see the table), this is the general idea of
multiple back-ends support



> >    - What is your evaluation of the potential usefulness of the
> >      library?
>
> I would choose to use ICU directly, as I couldn't see a reason not to,
> and I'd be concerned that the wrapper would not have wrapped some
> obscure function in ICU that I find I end up needing.
>

To answer I first point you to this:

  http://cppcms.sourceforge.net/boost_locale/html/appendix.html#why_icu

this:

  http://cppcms.sourceforge.net/boost_locale/html/appendix.html#why_icu_api_is_hidden

And also to this:

  http://cppcms.sourceforge.net/boost_locale/html/appendix.html#rationale_why

And remind that not everything is implemented in terms of ICU (message translation)
and allows to use successfully non-ICU backends.

However, in certain cases ICU seems to be only reasonable
options (and most full featured). For example on Solaris and FreeBSD were
the OS and the GCC compiler does not provide reasonable locales support
ICU is only usable backends.

>
> Darren
>

Thanks for the comments.

Artyom