Re: [PATCH] builtin/diagnose.c: don't translate the two mode values

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

 



On 9/20/2022 1:06 AM, Alex Henrie wrote:
> These strings are not translatable in the diagnose_options array in
> diagnose.c. Don't translate them in builtin/diagnose.c either.
> 
> Signed-off-by: Alex Henrie <alexhenrie24@xxxxxxxxx>
> ---
>  builtin/diagnose.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/builtin/diagnose.c b/builtin/diagnose.c
> index cd260c2015..576e0e8e38 100644
> --- a/builtin/diagnose.c
> +++ b/builtin/diagnose.c
> @@ -22,7 +22,7 @@ int cmd_diagnose(int argc, const char **argv, const char *prefix)
>  			   N_("specify a destination for the diagnostics archive")),
>  		OPT_STRING('s', "suffix", &option_suffix, N_("format"),
>  			   N_("specify a strftime format suffix for the filename")),
> -		OPT_CALLBACK_F(0, "mode", &mode, N_("(stats|all)"),
> +		OPT_CALLBACK_F(0, "mode", &mode, "(stats|all)",
>  			       N_("specify the content of the diagnostic archive"),

In terms of the existing string, this makes sense. Initially, I
thought that maybe we would rather have N_("mode") to match the
N_("format") in the above. Then, I went poking around to see what
patterns we had for these across the codebase (never a good idea).

An example similar to what you propose exists in builtin/branch.c:

		OPT_CALLBACK_F('t', "track",  &track, "(direct|inherit)",
			N_("set branch tracking configuration"),
			PARSE_OPT_OPTARG,
			parse_opt_tracking_mode),

or this instance in builtin/checkout-index.c:

		OPT_CALLBACK_F(0, "stage", NULL, "(1|2|3|all)",
			N_("copy out the files from named stage"),

In diff.c, the descriptors exist in angle brackets, so the right thing
would be N_("<mode>"). This seems non-standard compared to most other
places.

Here is a similar stale translatable regex in diff.c:

		OPT_CALLBACK_F(0, "diff-filter", options, N_("[(A|C|D|M|R|T|U|X|B)...[*]]"),
			       N_("select files by diff type"),

So if you are looking into these kinds of replacements, it might be
good to add instances like this. They are less important to the 2.38.0
release, though.

This long-winded email is all just to say that I've looked into the
standard way to handle this and agree that you are changing the code
to match our best practices.

Thanks,
-Stolee



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux