Re: i18n/l10n summary

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Paul Eggert <eggert@cs.ucla.edu> schrieb am Do., 1. Juni 2017 um 07:18 Uhr:

> Thanks for that patch: it's a good move forward for i18n. Some suggestions:
>
> * Today I fixed the bug with "%%" and the 'error' function, so there's no
> need
> for a FIXME or a workaround any more.
>
> * In strings.texi, reorder the format spec description so that it matches
> the
> textual order of a format spec. This should lessen confusion.
>
> * Allow field numbers in a %% spec. All other components of a format spec
> are
> allowed in %%, so odd to report an error for just field numbers.
>

The reason I banned that initially is that the behavior for the case "%1$%
%d" is confusing: will the %d take argument 1 or 2? (We should ban such
mixing instead, see below.)


>
> * There is no need for a special diagnostic for field numbers greater than
> PTRDIFF_MAX. Just use the same diagnostic other too-large field numbers
> use.
> This avoids a need for an alloca.
>
> * Reword "Invalid field number `0'" to "Invalid format field number 0" to
> make
> it more obvious that it's a format and there's no need to quote the 0.
>
> Proposed further patch attached (it addresses the above points), along
> with a
> copy of your patch rebased to current master for convenience.
>

Thanks, feel free to push.

Two further things:
- Probably there's a bug lurking because the info[n] ought to be indexed by
specification index, not argument index. Something like (format "%1$c %1$d"
?a) will probably do the wrong thing (untested).
- We should ban mixing explicit and implicit field numbers, like POSIX
printf(3) does. The gain from allowing to mix is negligible, and it makes
the implementation and the documentation needlessly complex.

[-- Attachment #2: Type: text/html, Size: 2314 bytes --]