[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: i18n/l10n summary

From: Philipp Stephani
Subject: Re: i18n/l10n summary
Date: Thu, 01 Jun 2017 08:17:37 +0000

Paul Eggert <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]