Re: [PATCH v2 2/2] blame: use different blame_date_width for different locale

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 20, 2014, 21:40 UTC
Message-ID: <7vbnvvllx4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <07e4dcdc98b5eb9c78b9ed53bf2adc3b33139b67.1398010052.git.worldhello.net@gmail.com>

Jiang Xin <worldhello.net@gmail.com> writes:

Show 33 quoted lines

> When show date in relative date format for `git blame`, the max display
> width of datetime is set as the length of the string "Thu Oct 19
> 16:00:04 2006 -0700" (30 characters long).  But actually the max width
> for C locale is only 22 (the length of string "x years, xx months ago").
> And for other locale, it maybe smaller.  E.g. For Chinese locale, only
> needs 16-character width.
>
> Set blame_date_width as the display width of _("4 years, 11 months
> ago"), so that translators can make the choice.
>
> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
> ---
>  builtin/blame.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 0a0a858..9350ea3 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -2340,7 +2340,15 @@ parse_done:
>  		blame_date_width = sizeof("2006-10-19");
>  		break;
>  	case DATE_RELATIVE:
> -		/* "normal" is used as the fallback for "relative" */
> +		/* TRANSLATORS: what we care about is not the content itself,
> +		   but the display width of this string.  We use the width of
> +		   the string as the max width of the datetime in relative
> +		   format.  For English and many other languages, "4 years,
> +		   11 months ago" is the longest one among "89 seconds ago",
> +		   "89 minites ago", "35 hours ago", "13 days ago", "10 weeks
> +		   ago", "in the future" and many others. */
> +		blame_date_width = utf8_strwidth(_("4 years, 11 months ago")) + 1; /* add the null */
> +		break;

This is not wrong per-se, but I am not sure if translators would understand that "years and months ago" may not be the longuest variant for their language and they are asked to use "89 seconds ago" if the translation of that is longer than the translation for "4 years, 11 months ago" in their language, with the given explanation.

How about dropping the second sentence "We use..." and end the comment with something like:

	ago", "in the future" and many others.  It is possible that
	the translation of "89 seconds ago" may be the longest
	possible translation in your language (then by definition,
	it would be longer than the translation of this string in
	your language), and in such a case, please write the
	translation of "89 seconds ago" here.

Actually, even though "many others" is correct, the possibilities are within a bounded set of template i18n formats, no? I wonder if it would be nicer to the translators if we did not use a single "representative string" here, but add a helper function to date.c that goes something like:

    int date_relative_maxwidth(void)
    {
        struct strbuf buf = STRBUF_INIT;
        static int length;

        if (length)
            return length;

        strbuf_addf(&buf, _("in the future"));
        length = (length < buf.len) ? buf.len : length;
        strbuf_addf(&buf, Q_("%lu second ago", "%lu seconds ago", 89), 89);
        length = (length < buf.len) ? buf.len : length;
        ...
        strbuf_addf(&buf, Q_("%lu year ago", "%lu years ago", 9999), 9999);
        length = (length < buf.len) ? buf.len : length;

        return length;
    }

immediately after the definition of show_date_relative() and used it in this codepath?

Of course, given a date that is far enough into the future, the actuall length is unbounded, so this approach will not come up with the absolute minimum width to align all lines (you would need to do a two pass, measuring how wide all timestamps that would appear in the output before producing the first line of the output---but I do not think it is worth it, and as long as we do not overflow the buffer, showing occasional misalignment for a line that came from year 27342 is much better than a worse latency-to-first-output).

>  	case DATE_LOCAL:
>  	case DATE_NORMAL:
>  		blame_date_width = sizeof("Thu Oct 19 16:00:04 2006 -0700");