Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

From: Martin Ågren <martin.agren@gmail.com>
Date: May 29, 2018, 10:30 UTC
Message-ID: <CAN0heSry9ncTTzjw2fB=wxTAo3YPyQq-wbONpXCsfi_Syxfj-A@mail.gmail.com>
In-Reply-To: <xmqqtvqrggdt.fsf@gitster-ct.c.googlers.com>

On 29 May 2018 at 07:50, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> Martin Ågren <martin.agren@gmail.com> writes:
>
>>>  - allow callers to align 1st prefix (e.g. "error: ") with the
>>>    leading indent for the second and subsequent lines by passing the
>>>    second prefix with appropriate display width.
>>
>> I suspect this second prefix would always consist of
>> strlen(first_prefix) spaces? We should be able to construct it on the
>> fly, without any need for manual counting and human mistakes.
>
> I wouldn't be so bold to claim that, given especially that we are
> talking about i18n/l10n where byte count, character count and
> display width are all different even on a terminal with fixed-width
> font.

You are of course correct. I should have my morning tea before typing.

About the _("\t")-approach that you mentioned up-thread. It would allow a translator to adjust all the indentations for a particular language. To be clear, what you mean is _(" " /* 9 spaces */) to align nicely with "warning: ", which is the longest English string. Then the translator would translate the nine spaces and all of "fatal: " and others to padded strings, all of the same length (not necessarily nine). Correct?

That approach seems a bit shaky, if nothing else because we may one day similarly want to use nine "translated" spaces in some other context. Or maybe this is actually i18n-best-practices.

It also means that shorter prefixes are somewhat arbitrarily padded, just because there exists a longer prefix that some other code path may want to use. OTOH, if a "warning: " is followed by an "error: ", both lines/blocks would have the same indentation, which might perhaps be (slightly) preferable.

Martin