Re: Composing sentences makes them hard to translate

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[cc'ing bug-gnulib, since the bug really lies there, and bug-m4, since it
is a concrete example of an affected package.  This started at
http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00000.html.
Replies can probably trim all lists except bug-gnulib.]

According to Jim Meyering on 11/2/2006 5:35 AM:
> "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.

Since STRTOL_FATAL_ERROR is already a macro, is there any way we could use
token concatenation to output a preprocessed file with the final set of
strings for each input noun?  Does automake make it very easy to generate
a preprocessed-only output, and then feed that output (instead of
xstrtol.h) to xgettext?  Existing users may have to change slightly, by
passing a string literal instead of a variable (so the m4 example below
would have to change slightly), but the bulk of the work could be limited
to the xstrtol module in gnulib.  Or does this sound too hard to use cpp
to generate a file that is still acceptable to xgettext?

> 
> 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?

I agree that whatever we end up doing will probably be invasive, but if a
simple enough, and more importantly easy-to-maintain, solution is
proposed, it certainly does make the translator's job easier.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSfEX84KuGfSFAYARAlCQAKCsvZx65ibyMfXHCSZ1vz+ajLcx7gCeIz42
z5WH16jIwTu5mLaP6zphOaA=
=GkcQ
-----END PGP SIGNATURE-----