Boost logo

Boost :

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

It seems to me that the discution is getting nowhere because
you keep repeting that the string database is easier to deal
w/o clearly explainning why. You keep using negative words like
``digging through the code'' or ``track down''. These phrases
add nothing to the debate and using them does _not_ constitute
an argument. Saying that your approach is simplier doesn't
constitute an argument either: you need to say why it is simplier.

Karl Nelson wrote:

> > > 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.
> Syncing database strings is easier because when you change a
> string used by your program it nolonger has a translation. Thus
> when you rebuild the database it tells you that you need translations
> for these strings. No digging through the code to find out where
> they are or why they changed. It is now a matter for a translator
> not a coder.
> > > 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.
> In the shared library approach if I need to add an argument to
> void print_greetings( string name );
> to make it
> void print_greetings( string name ,string date);
> I need to track down all the code in 5 places and change
> both the print_greatings function and the place that envolves
> dealing with the output.

I don't think that adding

  << date

5 times to

  cout << whatever

is any harder than adding


5 times and

  << date

once to

  format (whatever) << whatever

> With gettext, you only have one
> piece of code so changing it changes once, and when you
> deal with straighening out the database it gets much simpler.

Again, why is it simplier ?

The code in the shared lib will be a list of simple and trivial
functions like:

  cout << "Cannot get file " << file_name
       << " because " << error << endl;

> > With my proposed solutions (1 to 3), the formating is indeed handled
> > in the locale-dependant part.
> One code base handling many languages is better than many
> code bases for many languages. That is the priciple of
> maximum reuse.

One string database is better than many string databases (one
per language). So keep all programs in English for maximum
reuse of the English language. ;-)

> Since following the approach of not having
> a format doesn't really contribute to boost, I don't see
> a point in discussing all the ways that i18n can be done without
> a format function.

My contribution is the idea that we shouldn't hav any formating
class in boost. In other words, it's a negative contribution.

> There is one method of i18n which uses
> format and some people wish to use it so I intend to contribute
> a class to assist in that effort.

I have also proposed a class I have written to do that.

Valentin Bonnard

Boost list run by bdawes at, gregod at, cpdaniel at, john at