Re: [PATCH] transport.c: mark push status strings for translation

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 13, 2013, 23:25 UTC
Message-ID: <20131113232529.GQ10302@google.com>
In-Reply-To: <1384345833-8345-1-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy wrote:

> Strings are only marked for translations, the actual lookup is delayed
> until inside print_ref_status(), so we only have to check for
> porcelain flag once.

I was confused about what this means (why would it be faster to call gettext() once inside print_ref_status() instead of once per caller in the argument to print_ref_status()?) until I looked at the code. I guess you mean something like

	Mark strings like "[up to date]" passed to print_ref_status() for
	translation with N_() instead of _() so they can remain untranslated
	in porcelain mode.

> While at there, mark some error strings in git push for translation
> too.

Thanks.

[...]

> +++ b/transport.c

[...]

Show 10 quoted lines

> @@ -627,16 +628,17 @@ static void print_ref_status(char flag, const char *summary, struct ref *to, str
>  		else
>  			fprintf(stdout, "%s\n", summary);
>  	} else {
> -		fprintf(stderr, " %c %-*s ", flag, TRANSPORT_SUMMARY_WIDTH, summary);
> +		int width = TRANSPORT_SUMMARY_WIDTH;
> +		const char *localized_summary = _(summary);
> +		/* compensate the invisible bytes in utf-8 strings */
> +		width += strlen(localized_summary) - utf8_strwidth(localized_summary);
> +		fprintf(stderr, " %c %-*s ", flag, width, localized_summary);

Nit: "Compensate for the ...".

What would happen if 'width' became negative? That can't happen because none of the doublewidth characters are ASCII characters, so the question is just academic, but maybe it's worth a note in the comment to avoid slowing down people reading.

>  		if (from)
>  			fprintf(stderr, "%s -> %s", prettify_refname(from->name), prettify_refname(to->name));

I'm not sure this is correct for right-to-left languages. Something to solve another day.

The rest looks good.

If the commit message is clarified,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>