Paul Eggert <[EMAIL PROTECTED]> wrote:
> "Göran Uddeborg" <[EMAIL PROTECTED]> 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 :-)
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
