generic: fix unit symbols and their formatting

[getsnoopy]

This commit changes some of previously pending abbreviations to their official unit symbols, and fixes some of the unit symbols which had typographical errors. It also fixes the formatting of some incorrectly formatted symbols to comply with SI, ISO, and IEC standards.

Signed-off-by: Varun Varada [email protected]

[jow-]

Hi, thank you for your work on this. I'm fine with the spelling fixes but not the base conversations, this should be done in a separate commit / PR if at all.

[hnyman]

I am not sure if I like the proposed changes.

Being an old-timer, megabyte has always been 1024x1024, and the proposed "mebibyte" is quite incomprehensible. Never heard about that...

Sure, there has always been some confusion, as the binary based units are naturally related to physical things like flash size (8 MB, not 8.4 MB or 8 MiB), while the some OEMs like hard disk manufacturers have still used the 10-based calc for advertised hard disk sizes.

Similarly, although the small "b" for bit and big "B" for byte has been the normal for ages, there are still people who do not know that. So the cosmetic changes in style of KByte-->kB feel like decreasing information content, although quite right be themselves.

[getsnoopy]

@jow- I removed the base changes from this PR; I'll make them in a separate one.

@hnyman The prefixes "kilo-" and "mega-" have always meant powers of 1000, it's just that early computer scientists have used them incorrectly while the rest of the population has always known them to be what they actually mean, so the hard drive manufacturers have used the terms correctly as well. This confusion has been corrected and is standard now as of 1998. Same thing with b instead of bit for bit(s).

[stangri]

@getsnoopy while I certainly appreciate your gigantic effort towards SI compliance, I personally would strongly prefer if you removed the extra spacing between numerical values and denominators in the 3 cases above.

[jow-]

Another problem is that the additional space introduces potential word wrapping in unexpected/undesired spots. And typographically it indeed looks funny - probably U+202F (NARROW NO-BREAK SPACE) should be used instead.

[getsnoopy]

@stangri I understand some people don't like the spaces, but that seems quite subjective. On the other hand, 3m means "3 million", whereas 3 m means "3 metres"; only 3 min means "3 minutes". Similarly, 4s means "fours", whereas 4 s means "four seconds". The space is not cosmetic. We should not depend on context to write units properly.

@jow- Good point, I forgot about wrapping issues because I thought these are inserted into bounding boxes with enough space. I don't know if the NARROW NO-BREAK SPACE is appropriate though, since that is used to replace the comma as the thousands separator (e.g., "10 000" instead of "10,000"). I can change it to the U+00A0 (NO-BREAK SPACE).

[jow-]

U+00A0 is too wide and makes things like 2 h 2 min 2 s look weird.

[getsnoopy]

I think the code formatting is making it look weird because it uses a fixed-width font. It would look more like "2 h 2 min 2 s". Though, I could be convinced by "2 h 2 min 2 s" (with thin spaces) as well. I'll change them.

[stangri]

Food for thought: https://forum.openwrt.org/t/poll-how-should-the-time-be-presented-in-webui/66585.

[getsnoopy]

I have no problem changing it to the hh:mm:ss format, as this is a valid and international format to represent time durations as well.

[getsnoopy]

@jow- I've updated the code as discussed.

[systemcrash]

No response

[knarrff]

Hi,

I am not quite sure which response would have been expected if not from a developer with merge rights. Was this PR superseeded by something else or fixed in another way?

thanks.