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

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-08-24 10:36:55

Karl Nelson wrote:

> > > > 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''.
> 
> Number 2 is almost worse than number 1 in that you constantly
> have to be syncing changes between the multiple branches.  The result
> it that every time you add a new function which deals with
> both input and some algorithm you have to resync and adjust for
> all the languages.  Assuming that you are writing a really
> international program with Germany, English, French, Japanese,
> and say Hebrew, this means deal with everything 5 times.

I don't know CVS very well so I don't know about difficult it is, 
and I will simply believe what you say.

> Number 3 is just a pain in the ass because you must make for total
> isolation of algorithm and input/output.  This is good practice though
> to the extent of total separation is a bit extreme.  You still
> have the problem of having to sync the functions in the many versions
> of the shared libraries. 

You still have to sync the formating strings in the different 
databases.

> So if you need to add an extra argument to
> be displayed that means changing 5 pieces of code.

You still have to change 5 formating strings. I don't understand 
why it is easier.

> Compared to maintaining 5 pieces of code maintaining one using
> appropriately powerful i18n classes, most programmers would likely
> chose the one.    Nothing is stopping you from maintaining the 5 though
> as it is always an option.
> 
> > > 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 ?
> 
> All strings are passed through get_text from which a database
> of strings is built.  This can be translated and when the locale
> of the program does not match the locale of the program, the
> program strings are hashed, looked up in the translation table, and
> then displayed.  The result is at least for output many languages
> can be written at once.  GNOME widgets hands that other end of
> the spectrum taking in input in left to right or right to
> left fashion.  The Text editor widget works in native UTF-8
> format and provides editing.  In other words unless your
> code is parsing and altering the text you don't worry about i18n.

With my proposed solutions, once you have moved all the 
language-dependant printing code to a shared library, you 
don't have to worry about i18n either.

With the GNOME solution, you still have to call gettext, and to 
use format string instead of the usual stream code.

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

> Apparently it is a GNU extension.  Unfortunately it wasn't marked
> as such.  I mistook it for part of the standard as they hadn't
> marked it as GNU only.

And it doesn't appear in the man-page ostream(3C++) we have here.

> > 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.
> 
> I have erased that distinction entirely.  If you want something
> printed as a decimal use %d.  This does not specify the type as an int
> only the formating of float, int,  or your favorite custom type should
> be done like an int (no decimal place, specified number of places).
> Thus if you place a complex through a %d, it will just make sure the
> numbers are printed in decimal.
> 
> Unlike other codes which use printf format, I don't make any attempt
> to enforce the "type" nature of the printf spec.  It simply isn't
> natural or necessary. 

I think we are in violent agreement.

> The format aspect of %d, %x, %o, %e, %s however
> is quite reasonable.  Moreover, as the number of decimal points on
> monetary units and display of numbers is an i18n issue, the specification
> of them in the format string is beneficial.

With my proposed solutions (1 to 3), the formating is indeed handled 
in the locale-dependant part.

-- 
Valentin Bonnard