Re: Composing sentences makes them hard to translate

[Jim Meyering]

"Göran Uddeborg" <address@hidden> wrote:

> Paul Eggert writes:
>> True, but how would we fix it?
>
> Wouldn't it be possible to enumerate the objects, just as you do for
> the errors?  That is, you would call
>
>     STRTOL_FATAL_ERROR (spec, block_size, e);
>
> where "block_size" is a value in an enumeration type defined in
> xstrtol.h similar to strtol_error.  Then you could collect all the
> error messages in a two-dimensional table, and do a lookup in the
> _STRTOL_ERROR function.  In this way the messages would still be
> collected in one place and not very hard to maintain?

That would work if the uses of STRTOL_FATAL_ERROR were all
in one package, or if each package had its own copy of xstrtol.h.
But the uses Paul showed were all from coreutils.  There are other
packages that use STRTOL_FATAL_ERROR with different strings.
And since xstrtol.h comes from gnulib, we're all using the same
copy.  Obviously, every package maintainer cannot require a new
row and/or column in this shared table, just because they're
diagnosing a new type of error.

Here's an idea -- perhaps too ambitious...
Imagine a pre-build process that would automatically scan the
package sources for uses of STRTOL_FATAL_ERROR and then generate
the code (including translatable strings) to perform the mapping.
The only constraint is that there has to be some convention
for mapping a parameter like block_size (an enum value) to the
the string "block size" when generating the full diagnostics.

For a concrete example, consider this use from lib/human.c:
    STRTOL_FATAL_ERROR (spec, _("block size"), e);
with the proposed scheme, do this instead:
    STRTOL_FATAL_ERROR (spec, STRTOL_OBJ_block_size, e);
where xstrtol.h would include a new generated header file
containing a definition for STRTOL_OBJ_block_size.
Then, something would parse that source file (human.c), notice the use
of this STRTOL_OBJ_block_size symbol, and create an enum declaration
  enum STRTOL_OBJ
  {
    ...
    STRTOL_OBJ_block_size,
    ...
  };
Then, code much like what is already in xstrtol.h
(defining STRTOL_FATAL_ERROR) could be generated,
but with the twist: in each branch of the switch-on-LONGINT_* statement,
there would be another switch stmt, this time on the new STRTOL_OBJ
enum value.  Each of the three diagnostics handling the
STRTOL_OBJ_block_size case would have the entire diagnostic (not composed),
including the derived "block size" words.

But there are still limitations with the above.
For example, GNU m4 has this use of STRTOL_FATAL_ERROR:

    $ grep msgid src/main.c
    size_opt (char const *opt, char const *msgid)
        STRTOL_FATAL_ERROR (opt, _(msgid), status);

and these uses of size_opt:

    src/main.c:     size = size_opt (optarg, N_("nesting limit"));
    ...
    src/main.c:     size = size_opt (optarg,
    src/main.c-                      N_("debug argument length"));

But it's easy to avoid causing compatibility problems.
Just choose a new name.

However, this is a rather involved and invasive change, all
for the sake of slightly better diagnostics while keeping
the overall process maintainable.
Is it worth the effort?