This commit introduces new utility component - ShortNumber. It should
work almost the same way as original shortNumberFormat function,
though it also localizes units and accepts one more prop - renderer.
Renderer is a function that takes rendered short formatted number
and also ready-to-pluralize number to format display result accordingly.
Ready-to-pluralize number allows to correctly select plural for
compactly notated numbers, respecting thousands and other units.
Issue #12451 accurately describes the issue with using raw numbers
when replacing counter with short version. In short, it doesn't work
with languages such as Russian, that require different plurals,
according to the unit number was compacted to.
All previous usages of shortNumberFormat were replaced with new
function, and as it became unused, it was removed to avoid misleading.
This commit introduces new utility component - ShortNumber. It should
work almost the same way as original shortNumberFormat function,
though it also localizes units and accepts one more prop - renderer.
Renderer is a function that takes rendered short formatted number
and also ready-to-pluralize number to format display result accordingly.
Ready-to-pluralize number allows to correctly select plural for
compactly notated numbers, respecting thousands and other units.
Issue #12451 accurately describes the issue with using raw numbers
when replacing counter with short version. In short, it doesn't work
with languages such as Russian, that require different plurals,
according to the unit number was compacted to.
All previous usages of shortNumberFormat were replaced with new
function, and as it became unused, it was removed to avoid misleading.
Conflicts:
- `.env.production.sample`:
Upstream changed it completely.
Changed ours to merge upstream's new structure, but
keeping most of the information.
Conflicts:
- `.env.production.sample`:
Upstream changed it completely.
Changed ours to merge upstream's new structure, but
keeping most of the information.
Some translations of that string are single-line, which somehow seems to make
Crowdin issue a blank newline at the end of those translations.
This, in turns, leads to different results when running “i18n-tasks normalize”
depending on the version of libyaml installed, making the CI fail if it
runs a different version than whoever ran “i18n-tasks normalize”.
Since there is no real reason for that source string to be multi-line (it is
only displayed in HTML, without replacing newlines by <br/> tags),
attempt to fix Crowdin export by making the source string single-line.
Some translations of that string are single-line, which somehow seems to make
Crowdin issue a blank newline at the end of those translations.
This, in turns, leads to different results when running “i18n-tasks normalize”
depending on the version of libyaml installed, making the CI fail if it
runs a different version than whoever ran “i18n-tasks normalize”.
Since there is no real reason for that source string to be multi-line (it is
only displayed in HTML, without replacing newlines by <br/> tags),
attempt to fix Crowdin export by making the source string single-line.