bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please cut up help text of xargs into manageable translatable chunks


From: Benno Schulenberg
Subject: Re: please cut up help text of xargs into manageable translatable chunks
Date: Mon, 25 Feb 2013 19:46:30 +0100

Hi Bernhard,

On Mon, Feb 25, 2013, at 12:03, Bernhard Voelker wrote:
> On 02/10/2013 10:01 PM, Benno Schulenberg wrote:
> >   "Mandatory and optional arguments to long options are
> >   also mandatory or optional for the short option.\n"
> 
> I slightly disagree - it's sometimes not so easy for the user
> to remember how mandatory and optional option's arguments have
> to be or can be passed. The following example illustrates this:
> 
>   -I R                         same as --replace=R (R must be specified)
>   -i[R], --replace[=R]         replace R in initial arguments with names read
> 
> While R *can* be separated by a space from the -I option (i.e. mandatory),
> it *must* be passed without a space for the -i option (i.e. optional).

To me that makes perfect sense: when an option requires an argument,
the command will eat kilometres of whitespace to find it, but when an
argument is optional, it necessarily must follow immediately after the
option, otherwise the command won't know that it belongs to the option.
It requires a moment's thought, yes.  But people can always use "=R",
just like for the long option, if they don't want to think.

(Also, to be really nitpicky and drive us off the cliff: for a mandatory
argument the space between option and argument is not required,
so to be really correct, the description for -I would have to be:

  -I[ ]R                         same as '--replace=R'

And I guess you don't want to go there either.  Better then: "Arguments
to long options are also mandatory/optional for the short ones.")


> You mentioned coreutils below - they're doing it like this. ;-)

Yes, for date, od and pr; not for split, tail and uniq.  I really like the
latter ones better.

> > And for --help and --version, why not use the standard ones
> > and put them at the end, like several coreutils and util-linux
> > commands start doing?
> 
> Done,

Well, what I meant was:

  --help    display this help text and exit
  --version  display program version and exit

> Attached you'll find the updated patch.

Several more nitpicks:

S/COMMAND INITIAL-ARGS.../COMMAND [INITIAL-ARGS].../
    (the initial arguments are optional; at least they were
    in the old concise usage message)

s/blank space/whitespace/

s/input items/items/  (otherwise I read "input" as a verb,
    _and to be more similar to --null)

s/(R must be specified)//   (superfluous, and thus confusing)

s/nonblank/non-blank/g

s/up to/at most/  (phrasing similar things as similar as possible)

s/limit commands/limit length of command line/  (because it's not
    just the command, also the initial args etcetera; and similar
    phrasing again)

Regards,

Benno

-- 
http://www.fastmail.fm - Does exactly what it says on the tin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]