All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Julien Palard" <julien@palard.fr>,
	"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 10:03:48 +0200	[thread overview]
Message-ID: <220412.86tuayhga7.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqq5ynfh101.fsf@gitster.g>


On Mon, Apr 11 2022, Junio C Hamano wrote:

> Julien Palard <julien@palard.fr> writes:
>
>> In french we use a no-break space before colon, so with formatting
>> like:
>>
>>     printf("... %s: ...", _("some string"))
>>
>> We can't cleanly add our no-break space, so I think:
>>
>>     printf("... %s ...", _("some string:"))
>
> Sorry, but I do not quite buy this.  The above is a representative
> example of what we call "sentence lego", which is what we absolutely
> want to avoid, isn't it?
>
> We'd rather want to see
>
> 	printf_like_function(_("Use 'git %s' ...", "string"));
>
> when "string" is something that should not be translated to begin
> with (e.g. "add" to form "git add"), and different languages can use
> different conventions for quoting the command name (a translation
> may want to use something other than single-quotes, for example).
>
> And in a less optimal case,
>
> 	printf_like_function(_("%s: ...", _("string")));
>
> would be needed, when "string" is something that is to be translated
> (e.g. a phrase used as a label, like "Untracked files" in the code
> this patch touches).  I think the case you have is the latter one.

You're right, but wt-status.c is sentence lego galore, and that's been a
TODO since the i18n effort was started.

It's particularly hard to peel it apart, and doing so would require
e.g. having translators translate a string with embedded color formats,
or even git-for-each-ref embedded %(if...) formats.

But in lieu of that I don't see a reson for not taking this much more
narrow change, since it solves a practical issue for a major language...

>> diff --git a/wt-status.c b/wt-status.c
>> index d33f9272b7..ef0c276c3d 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,
>>  					     const char *how)
>>  {
>>  	const char *c = color(WT_STATUS_HEADER, s);
>> -	status_printf_ln(s, c, "%s:", what);
>> +	status_printf_ln(s, c, "%s", what);
>
> I.e. this one is better handled by
>
> 	status_printf_ln(s, c, _("%s:"), what);
>
> as _(...) in C-locale is original-language centric, where we want
> the label to be <phrase> immediately followed by a colon.  And that
> allows French translation to have nbsp before the colon.

In this case I think the change as suggested is better, translators get
zero context from "%s:", whereas "Untracked files:" being status output
is immediately obvious.

>>  	if (s->show_untracked_files) {
>> -		wt_longstatus_print_other(s, &s->untracked, _("Untracked files"), "add");
>> +		wt_longstatus_print_other(s, &s->untracked, _("Untracked files:"), "add");
>
> Then this <phrase>, to be used in the label above, can be without colon.
>
>>  		if (s->show_ignored_mode)
>> -			wt_longstatus_print_other(s, &s->ignored, _("Ignored files"), "add -f");
>> +			wt_longstatus_print_other(s, &s->ignored, _("Ignored files:"), "add -f");

It's a good rule of thumb to give translators the "whole thing", in this
case that's a heading, so despite other issues with lego'd "status"
output this particular string is following best-practices after this
change by Julien.

His commit message also doesn't mention it, but for existing "headings"
we already do this, e.g.:

    status_printf_ln(s, c, _("Changes to be committed:"));
    status_printf_ln(s, c, _("Changes not staged for commit:"));

etc., grep for status_printf_ln.*" in that file, so this is making
things consistent with that other code.

  parent reply	other threads:[~2022-04-12 10:01 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
2022-04-12  8:03   ` Ævar Arnfjörð Bjarmason [this message]
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=220412.86tuayhga7.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=flashcode@flashtux.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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 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.