Skip to content

feat: Indian lakh/crore grouping + locale-derived group sizes (v0.6) - #16

Merged
jlc488 merged 1 commit into
mainfrom
feature/v0.6-lakh-grouping
Aug 8, 2026
Merged

feat: Indian lakh/crore grouping + locale-derived group sizes (v0.6)#16
jlc488 merged 1 commit into
mainfrom
feature/v0.6-lakh-grouping

Conversation

@jlc488

@jlc488 jlc488 commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

The last backlog item. The Indian system groups the last three digits and then every two — 12,34,56,789, not 123,456,789 — which the uniform regex grouper couldn't express. That's why it sat demand-gated; now it's requested.

Added

group accepts a [primary, secondary] pair:

format('100000',   { group: [3, 2] })  // '1,00,000'      1 lakh
format('10000000', { group: [3, 2] })  // '1,00,00,000'   1 crore
<input data-numkey data-numkey-group="3,2">

The regex grouper is replaced by a right-to-left loop covering both uniform and non-uniform sizes. A plain number still means uniform grouping (41234,5678), and group: 0 now disables separators instead of building a pathological \d{0} regex.

Fixed — a latent bug this exposed

locale only derived the separator and decimal mark, so a field with locale: 'en-IN' rendered 123,456,789: right separator, wrong grouping for that locale. localeSeparators now also reports group sizes — read out of Intl's formatToParts integer runs, which is how CLDR models primary/secondary — and resolveOptions applies them. Locales with ordinary thousands grouping are unaffected; an explicit group still wins.

Not affected

Caret math counts significant characters (digits), so it is grouping-agnostic by construction — no changes needed there, and a caret test under lakh grouping proves it.

Verification

  • 12 new tests (112 total), including an exhaustive cross-check of both Indian and default grouping against Intl.NumberFormat across integer widths 1–15 — 0 mismatches.
  • Real browser, char-by-char (this repo has a history of DOM bugs that whole-value tests missed): 11,23412,3451,23,45612,34,56,789 with the caret tracking correctly at every step, plus a mid-string insertion (1,02,34,56,789, caret after the inserted digit).
  • Demo site locale switcher gains en-IN; verified rendering 12,34,567.89 while the canonical value stays "1234567.89".
  • Docs: new section in both READMEs, attribute + option tables, roadmap marks v0.6 shipped (backlog now empty).

The Indian system groups the last three digits and then every two
(12,34,56,789), which the uniform regex grouper could not express — the
reason this sat in the backlog.

- group now accepts a [primary, secondary] pair; the regex grouper is
  replaced by a right-to-left loop that handles both uniform and
  non-uniform sizes. A plain number still means uniform grouping, and
  group: 0 now disables separators instead of building a pathological
  regex (\d{0}).
- data-numkey-group="3,2" parses the pair; garbage falls back to 3, and
  a secondary of 0 means uniform.
- Fixes a latent bug the feature exposed: locale only derived the
  separator and decimal mark, so locale: 'en-IN' rendered 123,456,789 —
  right separator, wrong grouping for that locale. localeSeparators now
  also reports group sizes (read out of Intl's formatToParts integer
  runs, which is how CLDR models primary/secondary), and resolveOptions
  applies them. Explicit group still wins.
- Caret math is untouched: it counts significant characters (digits),
  so it is grouping-agnostic by construction.

Verified: 12 new tests (112 total) including an exhaustive cross-check of
both Indian and default grouping against Intl.NumberFormat across integer
widths 1-15. Also verified in a real browser char-by-char (this repo has
a history of DOM bugs whole-value tests missed): 1 -> 1,234 -> 12,345 ->
1,23,456 -> 12,34,56,789 with the caret tracking correctly, plus
mid-string insertion. Demo site locale switcher gains en-IN.
@jlc488
jlc488 merged commit b46fbff into main Aug 8, 2026
1 check passed
@jlc488
jlc488 deleted the feature/v0.6-lakh-grouping branch August 8, 2026 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant