From: Junio C Hamano <gitster@pobox.com>
To: Alexander Shopov <ash@kambanaria.org>
Cc: git@vger.kernel.org, worldhello.net@gmail.com
Subject: Re: [PATCH 4 1/1] parse-options: localize mark-up of placeholder text in the short help
Date: Sat, 28 Dec 2024 08:55:40 -0800 [thread overview]
Message-ID: <xmqqy0zz3fxv.fsf@gitster.g> (raw)
In-Reply-To: <20241228114221.10351-4-ash@kambanaria.org> (Alexander Shopov's message of "Sat, 28 Dec 2024 12:42:18 +0100")
Alexander Shopov <ash@kambanaria.org> writes:
> Subject: Re: [PATCH 4 1/1] parse-options: localize mark-up of placeholder text in the short help
It is more common to see "[PATCH v4 1/1]" around here. In fact, I
suspect that you have to fight the tool to have them produce "[PATCH
4 1/1]".
Not that it matters to me personally (as "git am" on the receiving
end will strip it), but when looking for a specific version of your
patch from the mailing list archive, people may find it harder than
necessary because of the subtle difference.
> i18n: expose substitution hint chars in functions and macros to
> translators
> ...
> In case the translator's writing system is sufficiently different than
> Latin the "<>" characters can be substituted by an empty string thus
> effectively skipping them in the output. For example languages with
> uppercase versions of characters can use that to deliniate
> replaceability.
>
> Alternatively a translator can decide to use characters that are
> visually close to "<>" but are not interpreted by the shell.
Very well written.
> diff --git a/parse-options.c b/parse-options.c
> index 33bfba0ed4..8904345c07 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -1076,11 +1076,23 @@ static int usage_argh(const struct option *opts, FILE *outfile)
> !opts->argh || !!strpbrk(opts->argh, "()<>[]|");
> if (opts->flags & PARSE_OPT_OPTARG)
> if (opts->long_name)
> - s = literal ? "[=%s]" : "[=<%s>]";
> + s = literal ? "[=%s]" :
> + /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
> + Change only the `<>' characters to something else if you use another convention for this.
> + Most translations leave this message as is. */
> + _("[=<%s>]");
This is way too wide. Documentation/CodingGuidelines should have
something to say on this, but in case it does not, we try to allow
those with 80-column terminals to read our code comfortably, and it
is even better to allow us to do so after a patch is quoted a few
times (i.e. adding a few columns on the left edge), so a practical
limit may be around 70-columns.
Also, our multi-line comments have opening slash-asterisk and closing
asterisk-slash on their own line.
This part is giving a help for the option value argument for a long
option, i.e. for "git subcommand --option[=<value>]", we are talking about
the "[=<value>]" part. It is not clear "command line argument name"
conveys that. Something along this line, perhaps?
The "<%s>" part of this string stands for an optional value given to a
command line option in the long form, and "<>" is there as a
convention to signal that it is a placeholder (i.e. the user should
substitute it with the real value). If your language uses a different
convention, you can change "<%s>" part to match yours, e.g. it might
use "|%s|" instead, or if the alphabet is different enough it may use
"%s" without any placeholder signal. Most translations leave this
message as is.
> + _("[=<%s>]");
> else
> - s = literal ? "[%s]" : "[<%s>]";
> + s = literal ? "[%s]" :
> + /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
> + Change only the `<>' characters to something else if you use another convention for this.
> + Most translations leave this message as is. */
> + _("[<%s>]");
Ditto, except that this is for "the short form".
> else
> - s = literal ? " %s" : " <%s>";
> + s = literal ? " %s" :
> + /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
> + Change only the `<>' characters to something else if you use another convention for this.
> + Most translations leave this message as is. */
> + _(" <%s>");
Ditto, except that this is for "a value given to a command line option",
not specific to either long or short form.
> return utf8_fprintf(outfile, s, opts->argh ? _(opts->argh) : _("..."));
> }
I'll queue with the following change on top.
Thanks.
parse-options.c | 55 ++++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git c/parse-options.c w/parse-options.c
index 8904345c07..3ff6a5d1fa 100644
--- c/parse-options.c
+++ w/parse-options.c
@@ -1076,23 +1076,48 @@ static int usage_argh(const struct option *opts, FILE *outfile)
!opts->argh || !!strpbrk(opts->argh, "()<>[]|");
if (opts->flags & PARSE_OPT_OPTARG)
if (opts->long_name)
- s = literal ? "[=%s]" :
- /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
- Change only the `<>' characters to something else if you use another convention for this.
- Most translations leave this message as is. */
- _("[=<%s>]");
+ /*
+ * TRANSLATORS: The "<%s>" part of this string
+ * stands for an optional value given to a command
+ * line option in the long form, and "<>" is there
+ * as a convention to signal that it is a
+ * placeholder (i.e. the user should substitute it
+ * with the real value). If your language uses a
+ * different convention, you can change "<%s>" part
+ * to match yours, e.g. it might use "|%s|" instead,
+ * or if the alphabet is different enough it may use
+ * "%s" without any placeholder signal. Most
+ * translations leave this message as is.
+ */
+ s = literal ? "[=%s]" : _("[=<%s>]");
else
- s = literal ? "[%s]" :
- /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
- Change only the `<>' characters to something else if you use another convention for this.
- Most translations leave this message as is. */
- _("[<%s>]");
+ /*
+ * TRANSLATORS: The "<%s>" part of this string
+ * stands for an optional value given to a command
+ * line option in the short form, and "<>" is there
+ * as a convention to signal that it is a
+ * placeholder (i.e. the user should substitute it
+ * with the real value). If your language uses a
+ * different convention, you can change "<%s>" part
+ * to match yours, e.g. it might use "|%s|" instead,
+ * or if the alphabet is different enough it may use
+ * "%s" without any placeholder signal. Most
+ * translations leave this message as is.
+ */
+ s = literal ? "[%s]" : _("[<%s>]");
else
- s = literal ? " %s" :
- /* TRANSLATORS: %s is a command line argument name, `<>' prompt the user to supply a value for it.
- Change only the `<>' characters to something else if you use another convention for this.
- Most translations leave this message as is. */
- _(" <%s>");
+ /*
+ * TRANSLATORS: The "<%s>" part of this string stands for a
+ * value given to a command line option, and "<>" is there
+ * as a convention to signal that it is a placeholder
+ * (i.e. the user should substitute it with the real value).
+ * If your language uses a different convention, you can
+ * change "<%s>" part to match yours, e.g. it might use
+ * "|%s|" instead, or if the alphabet is different enough it
+ * may use "%s" without any placeholder signal. Most
+ * translations leave this message as is.
+ */
+ s = literal ? " %s" : _(" <%s>");
return utf8_fprintf(outfile, s, opts->argh ? _(opts->argh) : _("..."));
}
next prev parent reply other threads:[~2024-12-28 16:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-21 19:14 [[PATCH] [RESUBMIT 2nd] Consistency for substitution hints (i18n) 0/1] Alexander Shopov
2024-04-21 19:14 ` [[PATCH] [RESUBMIT 2nd] Consistency for substitution hints (i18n) 1/1] parse-options: use localized substitution hints Alexander Shopov
2024-04-21 19:33 ` Junio C Hamano
2024-05-25 12:24 ` [PATCH 2 0/1] Allowing localized substitution hints in parse-options Alexander Shopov
2024-05-27 18:14 ` Junio C Hamano
2024-05-28 0:47 ` Jiang Xin
2024-05-25 12:24 ` [PATCH 2 1/1] parse-options: allow localized substitution hints in macros Alexander Shopov
2024-05-27 18:14 ` Junio C Hamano
2024-07-07 15:35 ` [PATCH 3 0/1] parse-options: localize mark-up of placeholder text in the short help Alexander Shopov
2024-07-07 15:35 ` [PATCH 3 1/1] " Alexander Shopov
2024-07-14 20:41 ` Alexander Shopov
2024-07-15 15:39 ` Junio C Hamano
2024-12-28 11:42 ` [PATCH 4 0/1] Localize " Alexander Shopov
2024-12-28 11:42 ` [PATCH 4 1/1] parse-options: localize " Alexander Shopov
2024-12-28 16:55 ` Junio C Hamano [this message]
[not found] ` <CAP6f5MkYL8PgRyf_paCYxL-LE5nUa2U1GQMsu2scLzJPSS=9Ag@mail.gmail.com>
2024-12-30 3:02 ` Jiang Xin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy0zz3fxv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ash@kambanaria.org \
--cc=git@vger.kernel.org \
--cc=worldhello.net@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.