Re: [boost] [locale] Review results for Boost.Locale library

Subject: Re: [boost] [locale] Review results for Boost.Locale library
From: Ryou Ezoe (boostcpp_at_[hidden])
Date: 2011-04-24 01:06:48

On Sat, Apr 23, 2011 at 10:46 PM, Chad Nelson
<chad.thecomfychair_at_[hidden]> wrote:
> The formal review of Artyom Beilis' Boost.Locale library, originally
> scheduled to run from April 7th through the 16th and extended through
> the 22nd, is now finished.
>
> Fifteen people cast votes on it, ten for acceptance and five against.
> Though not overwhelming, the two-to-one majority clearly indicates the
> consensus of the list. As such:
>
> Â  Â The Boost.Locale library IS ACCEPTED into Boost.
>
> The details follow, starting with the voters in favor, in the order
> their reviews were received:
> * John Bytheway
> * Steven Watanabe
> * Sebastian Redl
> * Fabio Fracassi ("possibly conditional")
> * Noah Roberts
> * Steve Bush
> * Volker Lukas
> * Paul A. Bristow
> * Matus Chochlik
> * Gevorg Voskanyan
>
> Those opposed:
> * Ryou Ezoe
> * Phil Endecott (but "borderline")
> * Edward Diener
> * Mathias Gaunard
> * Vincente BOTET ("count my vote as 1/2 or 1/4 vote")
>
> There was also an early off-list review from Darren Cook which did not
> include a vote, only listing issues.
>
> There was a great deal of discussion around the library, and a number
> of issues detailed. The major ones (and some less major ones that were
> repeated by several reviewers) are summarized below, along with the
> initials of the reviewer(s) who brought them up and Artyom's responses.
> Note that although I followed the discussions closely, these are only
> the issues brought up in the formal reviews themselves.
>
> * Issue: date_time interface uses enums for periods, which is error
> Â prone and inconsistent with other date/time libraries. (JB)
> * Response: Will be addressed.
>
> * Issue: Reference documentation needs more detail or some things not
> Â clear; some terms used in the documentation are not defined or are
> Â defined too briefly; can't find headers that items are defined in
> Â from the documentation. (JB, SW, FF, PE, ED, MC)
> * Response: Will be addressed.
>
> * Issue: There are no prev/next links in the documentation, or tutorial
> Â can't easily be navigated. (DC, JB, SR, FF, MC)
> * Response: Looking into it.
>
> * Issue: Few examples include output. (JB)
> * Response: Will be addressed.
>
> * Issue: No examples in Asian languages; the library may have design
> Â flaws that are not apparent without them. (DC)
> * Response: [Artyom has indicated to me (privately) that he's adding
> Â such examples. -- CN]
>
> * Issue: The translation system requires narrow-character tags, making
> Â it English-centric. (RE, ED)
> * Response: The library implements the most popular and most widely
> Â used message-catalog format. It is not perfect, but it is the best
> Â system currently available. There may be a work-around if you really
> Â must use wide-character languages under Windows.
>
> * Issue: Support for wchar_t/UTF-16 is unclear. (RE, ED)
> * Response: Wide characters are fully supported.
>
> * Issue: Doesn't support Win32 API as a backend. (RE)
> * Response: Misunderstanding, Win32 API backend is fully supported.
>
> * Issue: boost::locale::format is not compatible with boost::format.
> Â (FF, NR)
> * Response: boost::format is too limited for use in localization, and
> Â throws on any error, which means that a translator error could crash
> Â the program.
>
> * Issue: boost::locale::date_time is not compatible with
> Â boost::date_time. (FF)
> * Response: An unavoidable consequence of the differences between them,
> Â which are necessary due to support for locale independence and
> Â non-Gregorian calendars.
>
> * Issue: Boundary analysis is only available when using ICU. (FF)
> * Response: At present, only the ICU backend supports proper boundary
> Â analysis.
>
> * Issue: Little documentation on the toolchain needed to extract
> Â strings and translate them, or the versions required. (FF, NR)
> * Response: Will be addressed.
>
> * Issue: Concerns about relying on GPL/LGPL-licensed tools, or their
> Â availability on all platforms, or recommendations to write a Boost
> Â version of these tools. (NR)
> * Response: Reimplementing these is non-trivial and unnecessary; the
> Â licensing for these tools does not affect the programs developed
> Â with them. All are available for all platforms; will add explicit
> Â instructions for getting the latest versions for Windows.
>
> * Issue: Use of strings instead of symbols for language and encoding
> Â makes run-time errors that could be compile-time errors. The most
> Â common ones should be symbols. (PE)
> * Response: There are dozens of character encodings, and even more
> Â locales, and no way to determine which ones are the most common. Not
> Â all encodings are supported by all backends or OS configurations.
> Â Names ignore case and non-alphanumeric characters, which should
> Â minimize errors that could be generated from them. utf_to_utf
> Â transcoding will be added.
>
> * Issue: Error handling (in conversions) is very basic. (PE)
> * Response: An unavoidable limitation of the backends.
>
> * Issue: Code could use more commenting. (PE, VL)
> * Response: Noted, will be addressed in the future.
>
> * Issue: Some documentation phrasing is confusing, or could use a
> Â native English speaker's input. (SR, VL)
> * Response: Will be addressed as discovered.
>
> * Issue: There are no lists of valid language, country, encoding, or
> Â variant strings. (ED)
> * Response: Listed in standards ISO-639 and ISO-3166, which are
> Â referenced in the library's documentation. These standards are
> Â updated occasionally, and should be referred to directly for the
> Â latest information.
>
> * Issue: Only works on contiguous, entirely-in-memory strings. (MG)
> * Response: All current backends require this, and it satisfies the
> Â vast majority of use-cases.
>
> * Issue: Boundary analysis goes through the entire string and returns a
> Â vector of positions. (MG)
> * Response: Not perfect, but given the limitations of the existing
> Â backends, it is reasonable.
>
> * Issue: The library's interface is not generic enough, or independent
> Â enough of the libraries that it wraps. (VB)
> * Response: The interface is similar to that of every other i18n
> Â library, and should make as few assumptions as possible. It should
> Â not be changed.
>
> * Issue: The date-time code should be merged into Boost.DateTime. (VB)
> * Response: Date-time code is locale-dependent by its nature, and is
> Â more natural in Boost.Locale. Updating Boost.DateTime to do everything
> Â that Boost.Locale's library does would require a lot of work, and in
> Â all the time it has existed, only the Gregorian calendar has been
> Â implemented. There are Boost libraries that overlap others, so this
> Â is not a novelty.
> --
> Chad Nelson
> Oak Circle Software, Inc.
> *
> *
> *
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

I can't believe it is accepted.
There were just 15 people explicitly stated their opinion.
There was only one native non-western language speaker. Me.
I really hate to complain much, but this library is totally useless
for the Non-English speaker.

Library author said it is important to use English.
Because it allow us to easily translate to other languages.
Does it really matter if Non-English people don't bother to use this library?

Believe me, There are so many Boost users who don't know English at all.
They are good at using Boost library because there are enough translations.

This English-dependent library cannot be used by these users.
They CAN use English identifier in the source file. like name of
functions, classes, variables etc(badly If you ask me)
But text is written in their language.
There is no way they use English text.
The text in software is not just written by programmer alone.
Non-programmers also write text.
So this library requires English for anybody.

If anybody can use English. There is no need for localization in the
first place.
That means, if everybody can use this English-dependent library, the
purpose of this library, the localization, is unnecessary.

I think I found a another issue.
Even the English text cannot be express by ASCII alone.
There are many characters ASCII doesn't have. such as ®.

So this library need to maintain two almost identical English texts.
One for real English text which contains non-ASCII characters, and one
for unique ASCII identifier that is a argument of translate().

But enough of argument.
I just want to assure you all, this library will never be used by
non-English speaker.
Blaming people for not to use English doesn't work. They don't care.
Just like you don't care their language.

-- 
Ryou Ezoe