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 3 1/1] parse-options: localize mark-up of placeholder text in the short help
Date: Mon, 15 Jul 2024 08:39:38 -0700 [thread overview]
Message-ID: <xmqqjzhm7jgl.fsf@gitster.g> (raw)
In-Reply-To: <CAP6f5MkGQssKyAdgN3rbzfTZtPgETaSjpm3JevuaLg-vh_pNug@mail.gmail.com> (Alexander Shopov's message of "Sun, 14 Jul 2024 22:41:28 +0200")
Alexander Shopov <ash@kambanaria.org> writes:
> Will the patch for expose substitution hint chars be included in 2.46?
> Should I do anything more?
Sorry, I lost track. Did we resolve why "<>" is special and but
"[]" is OK to leave out of the translatable text? IOW, is there
much point in advising the translators that "<>" is something
specifically they are allowed to change?
Stepping back a bit, would translators (especially for languages
without any need for the ability to replace <> with something else)
understand when told
TRANSLATORS: change `<>' to other characters or leave as is
why anybody would want to change it in the first place? Stepping
back even a bit more, probably making it clear to them what these
instances of [<%s>], [=<%s>], etc., are doing would be sufficient
to help them making the right decision?
If a translator for a hypothetical language that uses say „%s“
reads
/* TRANSLATORS: <%s> here stands for an command line argument */
_("<%s>")
in the comment, wouldn't that be sufficient to tell them they are
allowed to change "<>" to "„“"?
Similarly, explaining [<%s>] as "optional command line argument",
would tell them that it is OK for them to replace not just <> but
also [] if their language requires such a change, no?
Thanks for pinging.
>> diff --git a/parse-options.c b/parse-options.c
>> index 30b9e68f8a..06d962b00e 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -1070,11 +1070,17 @@ 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: change `<>' to other characters or leave as is */
>> + _("[=<%s>]");
>> else
>> - s = literal ? "[%s]" : "[<%s>]";
>> + s = literal ? "[%s]" :
>> + /* TRANSLATORS: change `<>' to other characters or leave as is */
>> + _("[<%s>]");
>> else
>> - s = literal ? " %s" : " <%s>";
>> + s = literal ? " %s" :
>> + /* TRANSLATORS: change `<>' to other characters or leave as is */
>> + _(" <%s>");
>> return utf8_fprintf(outfile, s, opts->argh ? _(opts->argh) : _("..."));
>> }
>>
>> --
>> 2.45.2
>>
next prev parent reply other threads:[~2024-07-15 15:39 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 [this message]
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
[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=xmqqjzhm7jgl.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.