Subject: Re: [PATCH v2 2/7] strbuf: split out logic to humanise byte values

From: Junio C Hamano <[email-masked]>
Date: Mon, 15 Dec 2025 17:21:06 +0900

Justin Tobler <[email-masked]> writes:

> +char *strbuf_humanise_bytes_value(struct strbuf *buf, off_t bytes, unsigned flags)
>  {
> +	int humanise_rate = flags & STRBUF_HUMANISE_RATE;
> +
>  	if (bytes > 1 << 30) {
> +		strbuf_addf(buf, "%u.%2.2u", (unsigned)(bytes >> 30),
>  			    (unsigned)(bytes & ((1 << 30) - 1)) / 10737419);
> +		/* TRANSLATORS: IEC 80000-13:2008 gibibyte/second and gibibyte */
> +		return humanise_rate ? xstrfmt(_("GiB/s")) : xstrfmt(_("GiB"));
> ...
> }
>  void strbuf_humanise_bytes(struct strbuf *buf, off_t bytes)
>  {
> -	strbuf_humanise(buf, bytes, 0);
> +	char *unit = strbuf_humanise_bytes_value(buf, bytes, 0);
> +	strbuf_addf(buf, " %s", unit);
> +	free(unit);
>  }

The old "strbuf-humanise" used to treat the whole "<number> <unit>",
e.g., _("%u.%2.2u GiB"), as a single thing to be translated.
However, the new code requires that in all languages:

 - Decimal point in number MUST be "." (don't some Europeans prefer
   comma instead?);

 - Number MUST come before the unit;

 - Between the number and the unit, there has to be one and only one
   SP.

All of which could be a severe regression from localization's point
of view.

The first point among the above three can relatively easily
remedied.  It is a bit more involved, but it is possible to fix the
other two, too.