Re: Composing sentences makes them hard to translate

[Jim Meyering]

Paul Eggert <address@hidden> wrote:

> "Göran Uddeborg" <address@hidden> writes:
>
>> In the macro _STRTOL_ERROR in lib/xstrtol.h contains strings like
>>
>>    "invalid %s `%s'"
>>
>> where the first %s is some kind of object, different for different
>> calls.  This is problematic to translate, since the translation of
>> "invalid" would have different forms dependent on what the object is.
>
> True, but how would we fix it?  Here are the uses of that macro in
> coreutils:
>
> lib/human.c:477:    STRTOL_FATAL_ERROR (spec, _("block size"), e);
> src/od.c:1653:            STRTOL_FATAL_ERROR (optarg, _("skip argument"), 
> s_err);
> src/od.c:1662:            STRTOL_FATAL_ERROR (optarg, _("limit argument"), 
> s_err);
> src/od.c:1673:                STRTOL_FATAL_ERROR (optarg, _("minimum string 
> length"), s_err);
> src/od.c:1745:                STRTOL_FATAL_ERROR (optarg, _("width 
> specification"), s_err);
> src/pr.c:807:    _STRTOL_ERROR (EXIT_FAILURE, pages, _("page range"), err);
> src/pr.c:817: _STRTOL_ERROR (EXIT_FAILURE, pages, _("page range"), err);
> src/sort.c:675:  STRTOL_FATAL_ERROR (s, _("sort size"), e);
>
> If we changed the calls along the lines that you suggested, we'd
> have to change the first call to be something like this:
>
>     error (exit_failure,
>            (e & LONGINT_INVALID_SUFFIX_CHAR
>             ? _("invalid character following block size in `%s'")
>             : e == LONGINT_OVERFLOW
>             ? _("block size `%s' too large")
>             : _("invalid block size `%s'")),
>            spec);
>
> and we'd have to do something similar for each of the other seven
> calls.  This would be a pain to maintain: if we add another error code
> we'll have to go rewrite all the callers.  Also, it bloats the code.

Yep.  I think early implementations did exactly that.
But the combinatorial explosion dictated the current compromise.

> There is a tradeoff here between ease of maintenance and idiomatic
> translations.
>
> Hmm, I suppose I could be talked into changing things.  Jim, what do
> you think?  An advantage of the change (aside from making translations
> more idiomatic) is that it relies less on C macro magic.

I'm interested if there's a way to do it without
introducing too much duplication across those cases.
I'm keeping an open mind :-)