Internationalization support and format strings

[Bruno Haible]

Richard (Rikki) Andrew Cattermole wrote:
>> https://github.com/dlang/phobos/issues/10713
>
> https://github.com/dlang/phobos/pull/10714

Thanks for handling this one.

>> https://github.com/dlang/phobos/issues/10711
>
> I think its more that docs are wrong here, rather than 
> implementation.

Hmm, you mean, instead of specifying a fixed order:

Parameters:
     Position Flags Width Precision Separator

the spec should specify arbitrary order?

Parameters:
     empty
     Parameter Parameters
Parameter:
     Position
     Flags
     Width
     Precision
     Separator

If that is intended, then

1) Is it valid to specify two positions, two widths, two 
precisions, or two separators? For example
   %1$2$d
   %3#5d
   %.3.5d
   %,3,5d
And if it is valid, does the first 
position/width/precision/separator matter, or the last one?

2) Since Flags can start with a digit 0, how do you disambiguate 
Flags after Width, Precision, or Separator?
For example
   %40d
   %.50d
   %,50d

The current spec, with the fixed order, is better at avoiding 
these ambiguities.

>> https://github.com/dlang/phobos/issues/10712
>
Richard (Rikki) Andrew Cattermole wrote:
> I'm not sure about this one, it looks funky, but at least its 
> easy enough to work around with.

Such a workaround does not help me with the internationalization.

The situation with the internationalization is:

1) The programmer specifies a format string as a gettext() 
argument. For instance,
gettext("%s is replaced with %*s")
or
"%s is replaced with %*s".gettext

2) The translator decides whether they need reordering, and thus 
translates
"%s is replaced with %*s"
with
"%3$*2$d ersetzt %1$s"

3) The GNU msgfmt program verifies that the translator's 
translation "matches", based on the specification of format 
strings.

There is no programmer that could add a workaround, since the 
programmer is not involved after step 1. And the translator 
usually does not try their translations "live".

So, what is really needed here, is not a possible workaround but 
an implementation of std.format that is in sync with its 
specification.