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

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-08-21 12:53:33

On Sun, Aug 20, 2000 at 08:05:13AM -0700, Karl Nelson wrote:
> > --- 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. 

The first one certainly is -- it there to show, by contrast, 
that the third one is excellent. ;)

Seriously, you need to explain why the other two 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. 

Why ?

> 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) 

These are synonym for me.

> also increase code complexity. 

In term of number of functions, yes. The algorithms are just as 
simple (or complicated), only the modularity changes.

> Making branches for i18n would be strictly against GNOMEs concept
> of write once for all.

How do you write the strings once for many different languages ?

> Note, I am the library writter trying to
> provide tools to my users not the app writter. 

That's my case too.

> If boost isn't
> interested the class will simply appear in my library, Gtk--.

If boost isn't interrested, then boost probably doesn't care 
about where the class will appear.

> > > 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.  

For some reason I have never seen this function. Where is it 
from ?

> > 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.

Boost has no formating class. People have uploaded things in 
the vault.

> 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.

I didn't invented a totally new syntax, I took a shell-like 
syntax ($1, $*).

The ISO printf syntax is only about types and formating, my format 
syntax is only about position. Different goals, different solution.

> 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.

printf syntax is bad because it only allows a limited number 
of types; actually the fundamental reason why printf syntax 
is bad is because it deals with types.

>  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.

-- 
Valentin Bonnard