git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Julien Palard <julien@palard.fr>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"Sébastien Helleu" <flashcode@flashtux.org>,
	"Jean-Noël Avila" <jn.avila@free.fr>
Subject: Re: [PATCH] Make a colon translatable
Date: Tue, 12 Apr 2022 09:26:33 -0700	[thread overview]
Message-ID: <xmqq8rsaclom.fsf@gitster.g> (raw)
In-Reply-To: <CmgFntqFQcIxsSKePSKmmWvAMwsl-9shDqzWTT9GqI3S6PXNdhTTX6LypjY0l-R8B52pkh_MpYtq-NbbDjXT6EuZ9_S-QV4cUqxKhjZUpw8=@palard.fr> (Julien Palard's message of "Tue, 12 Apr 2022 07:30:10 +0000")

Julien Palard <julien@palard.fr> writes:

> I understand your comment while seeing my badly choosen example
> with `_("some string:")`, but in the patch isn't your proposition
> more sentence-lego-ish than mine? If I understand correctly you're
> proposing to replace:
>
>     printf("%s", _("Untracked files:"))
>
> with:
>
>     printf(_("%s:"), _("Untracked files"))

Hmph, I am talking about

diff --git i/wt-status.c w/wt-status.c
index d33f9272b7..f475194ff8 100644
--- i/wt-status.c
+++ w/wt-status.c
@@ -249,5 +249,5 @@ static void wt_longstatus_print_other_header(struct wt_status *s,
 {
 	const char *c = color(WT_STATUS_HEADER, s);
-	status_printf_ln(s, c, "%s:", what);
+	status_printf_ln(s, c, _("%s:"), what);
 	if (!s->hints)
 		return;

where the callers already supply _("Untracked files") and _("Ignored files")
without trailing colon in "what" when calling wt_longstatus_print_other(),
which is a direct caller that passes "what" to this function.

So, no, I am replacing

	printf("%s:", _("Untracked files"))

with

	printf(_("%s:"), _("Untracked files"))

and no other changes are required.  When translating "%s:", French
translation can insert nbsp before the colon to make it "%s :",
right to left languages may want to put their equivalent to colon
that comes after a heading on the left side of the "%s", etc.

> This hides information to the translator (the presence of a
> following colon while translating 'Untracked files').

With "Untracked files" and "Ignored files", we indicate certain
concepts and interpolate it in _("%s:"), i.e. a version localized to
adjust to the presentation convention of "label followed by a
separating colon".  Unless your language requires to translate
"Untracked files" differently when it is used as a "label" to be
followed by a separating colon and when it appears elsewhere in a
sentence, I am not sure how it helps to mark "Untracked files" as
appearing as a header label.

Besides, in the existing code, the form that is equivalent to

	printf("%s:", _("Untracked files"))

is being used, and where that "Untracked files" appear is two level
function calls away from the actual "%s:" (i.e. "label and
separator").  Aren't translators translating this string without
extra context?

> It would be
> OK if we were 100% sure no translations can be impacted by this. I
> only speak french and english, so I don't know. Maybe I should
> rename `what` to `heading`? I may clarify a bit, `what` make me
> feel it can be reused, but it's only used once alone on its line.

The way the function wt_longstatus_print_other() uses "what" and
"how" looks quite clear.  What kind of paths are being reported (are
they ignored files?  untracked files?  something else?) and how the
user can rectify the situation if they want these paths included in
the tracked set of paths.  I am afraid renaming to "heading" makes
it even less clear than leaving it to "what".  A word that indicates
that it refers to "category of paths" more clearly may make a good
replacement, but perhaps I am not understanding where exactly your
"this hides the information" comes from and makes you worry about
it.  Besides, would translators work off of .po and .pot files, not
the C-source?  Do they even have ready access to the variable names
to help them infer how the strings are used to begin with?

If translators truly benefit from knowing that the string "Untracked
files" is used as a heading, we could use /* TRANSLATORS: insn */
comment to help them.  Since I seem not to get where your concern
comes from, I cannot tell if it would help.

More info needed, I guess?

  reply	other threads:[~2022-04-12 16:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  7:02 [PATCH] Make a colon translatable Julien Palard
2022-04-11 19:29 ` Junio C Hamano
2022-04-12  7:30   ` Julien Palard
2022-04-12 16:26     ` Junio C Hamano [this message]
2022-04-12  8:03   ` Ævar Arnfjörð Bjarmason
2022-04-12 16:32     ` Junio C Hamano
2022-04-13 13:11       ` Jean-Noël Avila
2022-04-13 16:48         ` Junio C Hamano

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=xmqq8rsaclom.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=flashcode@flashtux.org \
    --cc=git@vger.kernel.org \
    --cc=jn.avila@free.fr \
    --cc=julien@palard.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).