On 29 May 2018 at 07:50, Junio C Hamano <[email protected]> wrote:
> Martin Ågren <[email protected]> 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
