On Mon, Apr 25, 2011 at 1:18 AM, Gevorg Voskanyan <v_gevorg@yahoo.com> 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