Boost logo

Boost :

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


On Mon, Apr 25, 2011 at 1:18 AM, Gevorg Voskanyan <v_gevorg_at_[hidden]> wrote:

> I understand the message translation module of Boost.Locale is not currently
> well-suited for use with non-ASCII keys. But what about other modules: number
> formatting, collation, boundary analysis, etc.? Do you consider them useless for
> non-English speakers too?

For Japanese. These features are all useless.
Although I don't know Chinese and Korean, I think following is also
true for them too.

Number and Date formatting:
There are so many possible ways to express numbers.
Some people want comma separation by 3 digits, other want 4 digits.
Some want 1000000 to be 100万(万 means 10000). some want 百万(百 means 100)。
Formatting based on locale doesn't work because there is no uniform format.

Collation and Conversions:
Japanese doesn't have concepts of case and accent.
Since we don't have these concepts, we never need it.

Boundary analysis:
What is the definition of boundary and how does it analyse?
It sounds too smart for such a small things it actually does.
I'd rather call it strtok with hard-coded delimiters.
Japanese doesn't separate each words by space.
So unless we perform really complicated natural language
processing(which is impossible to be perfect since we never have
complete Japanese dictionary),
we can't split Japanese text by words.
Also, Japanese doesn't have a concept of word wrap.
So "find appropriate places for line breaks" is unnecessary.
Actually, there are some rules for line break in Japanese.
These rules are too complicated and it requires more than text processing.
Same for Chinese and Korean.

Of course, strtok is still a handy tool and I appreciate yet another design.
But I think it's better be handled by more generic library, like Boost
String Algorithms.

-- 
Ryou Ezoe

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk