$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: mfdylan (dylan_at_[hidden])
Date: 2002-01-24 01:55:05
--- In boost_at_y..., Karl Nelson <kenelson_at_e...> wrote:
> 
> That would not well serve the purpose of allowing 
internationalization.
> String translation services use printf.  It is a large standard 
which
> we really should obey.  This point has been discussed multiple
> times on the list.  Positional simply does not serve the needs of
> a formating tool.
> 
> > By the way, Robert's approach doesn't mention about how to write 
Surely it's fair to assume most translation services understand the %
1 %2 %3 style?  It's used by the Win32 FormatMessage API if nothing 
else.  As for the problem of how to deal with a number directly after 
the digit, has anyone seriously ever needed more than 9 positional 
parameters in a sentence?  And does it really happen so often that 
breaking the string up into two is going to cause a major problem?
If not, then you just take the first digit after the % and you're 
done.  Simplifies parsing, and the pretty rare cases where you might 
want a fixed number directly after a positional parameters aren't 
likely to upset anyone too much.  If they do, then make the number a 
parameter too.
So
"Renaming file %1 in folder %2 to %12. OK?"
becomes
"Renaming file %1 in folder %2 to %1%3. OK?"
Even if the number is always '2' for now, there's a moderate chance 
in the future it might change, so inserting dynamically at runtime is 
doing no harm.
As for the formatting options (width/precision specifications and so 
forth), I really can't see a lot of point of encouraging continued 
use of the cryptic printf-style, which can hardly make translators' 
jobs easier.  The only reason I can see for keeping them part of the 
string is the possibility that in you want different hardcoded  
specifications across multiple languages.  I'm willing to hear a 
reasonable justification of why this is necessary (as opposed to 
dynamically determined specs where they may need to be different for 
different languages), but I certainly can't think of any.
As for using [], I was only finally warming to using % as an insertor 
when the [] idea was sprung on us all.
Now we are supposed to something like write
format("array\[[1]\] = [2]") [i] [array[i]];
as opposed to
format("array[%1] = %2") % i % array[i];
At least using '%<n>' the only time you'd require escaping of '%' is 
if you actually want to display % followed by a number - and % 
generally goes at the end of a number so that's pretty unlikely.  I 
guess something like:
"n mod 2 (notated n%%2) returns the least significant bit"
I'd prefer
format("array[%1] = %2", i, array[i]);
Although if you allow for manipulators between parameters, even with 
only 9 parameters you would have to support a helluva lot of template 
variants.  And I guess it's handy to be able to insert parameters one-
by-one if necessary.  To be honest I never really understood the 
argument against using '<<' - I assume the only reason was that the 
statement
cout << format("array[%1] = %2") << i << array[i] << ".\n";
Could either be an error (inserting too many parameters), or an 
intended insertion of ".\n" into the stream after the formatted 
message.  I probably opt on the safe side and say it's error and 
require extra parentheses:
cout << (format("array[%1] = %2") << i << array[i]) << ".\n";
I think I showed in another post how this can implemented with 
minimal code and fairly efficiently.
Dylan