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

From: jpanzer_at_[hidden]
Date: 2000-08-24 15:48:57

Valentin Bonnard wrote:

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

As a data point: Some applications need to be able to reference multiple
locales simultaneously.  Consider a web server based process (those are popular
nowadays...) that actually serves requests from multiple locales
simultaneously.  Of course you could implement this as a set of modules, all of
which are loaded dynamically and referenced via function pointers, but I don't
see how this buys you much over a table of strings.

Perhaps more importantly, for a large project I _really_ need to be able to
isolate your localized strings from my code so that translators can work on
just the strings without the possibility of breaking functionality.  The
strings also need to be in as simple a format as possible to allow
non-technical translators to work with them.  Otherwise you waste a lot of
engineering time copying strings back and forth.

All of this points to a restricted "little language" for strings as a superior
solution for internationalized software.  printf-style formats with position
info are fine IMHO, as long as they are rendered _safe_.  A typo in a
translated string should not crash my server; at worst it should produce an
ugly looking string.

-John Panzer