Re: [boost] i18n for streams (Was: Re: formatting manipulator for UTF-8)

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-20 10:05:13

> --- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> 
> > Streams have a bad tendency to cause pieces by breaking up text.
> > This presents a problem for translation as phrases often
> > must be translated as one unit with gettext.   Further, the use of a
> > stream fixes the order of which variables will be displayed which 
> > makes translation extremely awkward for languages where the order
> > does not match that of the original program.  As a result most codes
> > which are designed for i18n can't use streams.
> 
> Indeed code using streams cannot be gettextified (is that the 
> right word ?)
> 
> Instead of inventing a tiny formating language, rewritting
> i18n-dependant things in it, just write usual C++, and 
> translate the _code_ itself.

I am not inventing a formating language I merely allow
use of the very common one with streams.

  cout << format("This is a test %d %s") << int(1) << string("hello");

> There is no need to use gettext, just change the code reponsible 
> for formating and printing messages.
> 
> You can do that:
> - with conditionnal compilation (for the very old-fashionned :)
> - with CVS branchs: one branch = one language (probably 
>   quite complicated)
> - or rather, by moving all the formating code (ie all calls 
>   to iostream) into a DLL

All of these are extrodinarily bad ideas.  To favor maintaining
a larger code base in which you must track changes over multiple
banches over just setting gettext strings is ridiculous at its
face.  I18n that way is an employment act for a really dull
programmer.  And moving code the a shared library (which is what I
assmue you mean by DLL) also increase code complexity. 

Making branches for i18n would be strictly against GNOMEs concept
of write once for all.  Note, I am the library writter trying to
provide tools to my users not the app writter.  If boost isn't
interested the class will simply appear in my library, Gtk--.

> 
> > ostream.form().
> 
> What's that ?

Part of the standard which uses ellipsis.

  cout.form("This is a test %d %s",1,s.c_str());

For some reason C++ implements a printf with all the 
flaws of printf rather than something like a positional
formatter for streams.  

> > However, both
> > depend on the use of ellipsis which will not accept C++ types.
> 
> And we don't want to use the ellipsis anyway.

Of course not, hence my code.

 
> I have also implemented a class for positionnal args:
> 
> http://www.eleves.ens.fr:8080/home/bonnard/Boost/PosStream/
> 
> Typicall use is:
> 
>   boost::format(cout, "Cannot $1 at $2:$3\nCause: $4\n")
>     << "frobnicate" 
>     << "blaz"
>     << showbase << hex << uppercase << 10 
>     << "no more foobars";
> 
> Note that any formatter can be used.

Okay then this is really odd because boost has another
stream formater as well.  Which is what the rest of the
discussion was about.  Note yours is very much like mine, 
except mine uses printf indicators so I don't have to invent syntax.
Although if you read the doc on the code I sent, all of this was 
already explained.  I merely sent an introduction so that
interested parties know the scope of the problem.

Whether using printf syntax is good or bad is open for 
debate.  Our code bases both have compatible ideas asside from
the formatting string.  The other one (search for "basic i/o"
in the archives) is not compatible and uses template
based proxy to get ellipsis behavior.  Those obviously
the conflicts between the three code bases will need to be 
reconciled.

--Karl Einar Nelson