3 maj 2013 kl. 16.10 skrev Daniel Shahaf:
> It's a hack. It hardcodes the specific first and third arguments to
> the
> (os->errfn)("%s: %s: %c\n", _, "invalid option", _);
> call in APR's unix/getopt.c. The only benefit we get in return is
> translating six two-word error messages in option parsing.
This "only" benefit is precisely the one intended: to make a small set
of important error messages translatable.
Could you please enumerate the negative effects the patch would have,
in your opinion?
Since the patch:
1) solves an annoying problem,
2) does so by adding a small amount of code in a single place,
3) with robust failure modes (if anything breaks, we will just fall
back to the old behaviour),
4) without changing the behaviour in any way whatsoever for those
living in LANG=C,
5) a "proper" solution is likely to be a lot more invasive, involve
cross-project work, require new library versions and certainly would
not be done for 1.8.x for any x, and most likely will never happen,
it does not seem to be something that should be very controversial,
should it?
(That doesn't mean it cannot be improved technically, of course.)
> Anyway, how about this:
>
> static void
> emit_option_error(void *baton, const char *fmt, ...)
> {
> struct { FILE *stream; const char *argv0; apr_pool_t *pool; } *b =
> baton;
> va_list va;
> va_start(va, fmt);
> vfprintf(b->stream, fmt, va);
> va_end(va);
> svn_error_clear(svn_cmdline_fprintf(b->pool,
> _("%s: See '%s --help' or '%s --
> help <subcommand>'"),
> b->argv0, b->argv0, b->argv0));
> return;
> }
That does not address the problem at all; the apr_getopt messages are
still shown untranslated.
Besides, there already is a translated message after a failed option
parse ("Type '%s help' for usage.\n") and it is emitted after the
getopt has returned with an error, where it should be.
Received on 2013-05-04 13:56:02 CEST