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

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-23 15:49:31

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

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.  So if you need to add an extra argument to
be displayed that means changing 5 pieces of code.

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.

[...]
> > 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 ?

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.  

(Note I am not a great i18n expert here.  I merely am wrapping 
the code of the C library and providing the tools to make such
simpler.  I am simply repeating the GNOME i18n strategy as
I understand it.)

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

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

Read the thread "better i/o" in the archives a formatting 
class was in the late stages of review.

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

One can argue that formating should be a function of a "format"
command.  Positional information is simply a subset of the more
general problem of how to maintain strings for i18n code.

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

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

--Karl