Jiang Xin <worldhello.net@xxxxxxxxx> writes:
> 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@xxxxxxxxx>
> ---
> 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");
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html