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

Subject: Re: [boost] [locale] Review results for Boost.Locale library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-27 01:57:54

> >
> > The problem even if the source is  UTF-8 with BOM "שלום" would
> > be encoded according to locale's 8bit  codepage like 1255 or 936
> > and not UTF-8 string (codepage  65001).
> >
> > It is rather stupid, but this is how MSVC works or  understands
> > the place of UTF-8 in this world.
> >
> > Unicode  and Visual Studio is just broken...
> 
> The real obstacle for localization is  not a software which wasn't
> programmed for a localization in mind.
> We can  replace hard coded text.(whether the source code is provided or not)
> It's  rather tedious but straight forward task.
> Most program don't need a runtime  language switch anyway.
> Hard coded text is all right.
> 

Really? If so you probably havn't read the manuals
or did any real localization tasks beyond simple
converting several strings from one language to 
another.

And no, this isn't called localization. There way
too many things beyond this.

This remark and other different remarks about
for example the fact that you said "plural forms
should not be used" at some point in the review
make me doubt if you have real experience with
localization of a software at all.


> The real  obstacle is ASCII.
> If ASCII is used instead of UTF-8, UTF-16, or UTF-32, we  have to use
> ASCII compatible encoding.
> In Windows and for Japanese, it's  CP932(Microsoft variant of Shift-JIS).
> 

You are mixing US-ASCII and Windows "ANSI Encoding" all the
time - they are different things.

> In that case, we can't translate a  program simply replacing the text.
> Because Windows can't tell which encoding  it is(it can be anything, we
> can't detect it heuristically),
> we have to  explicitly specify it.
> 
> For example, an argument for every call of  CreateFont API's fdwCharSet
> parameter must be modified to  SHIFTJIS_CHARSET.
> 
> In Windows, software should use UTF-16.
> If a locale  library expect ASCII input, even though it support wchar_t
> output, I wonder  how many people actually use it.
> 

I don't understand how you still do not get 
what I have written many-many times.

The input it narrow string but the output can be
both narrow and wide string according to your
needs.

> By using ASCII input, this library  encourage to use ASCII.
> Another obstacle for real world  localization.
> 

US-ASCII is used as base line of all encodings. So the
software would in independent of various ways various
compilers see what encoding should be used.


Ryou,

Before you continue this "Crusade" against Boost.Locale,
please read the other post I have added on how can I implement
a way to handle natural-language specific keys.

You hadn't even related to it. So please, until
you really read things deeply and try to understand
the rationale (even if you disagree) don't bother
to ask again. Because I can't talk to someone
who does not relate to my posts in the list.

In the other mail I provided a solutions
how to make

   std::wstring something = wgettext("平和");

Or

   std::wstring something = wgettext(u8"平和"); // when MSVC will support it

To work correctly without any problems
in transparent way. And I had told that I will
implement this in Boost.Locale even that I think
it is wrong from localization point of view.

But you still talking about "bad-ascii-boost-loocale"

So enough is enough. I'm willing to do constructive
discussions but I'm not going to listen
any more till you'll change the attitude. 

I hope I hadn't offended you in any way, but I
just can't continue the discussion the way
it is.

Best Regards,
  Artyom