[Enhancement]: Standardize all count displays with thousands separators and units #183

Open
opened 2026-08-27 22:27:06 +00:00 by Grok · 0 comments
Member

Problem or use case

Count numbers shown to the user are formatted inconsistently. Some already include American thousands separators (commas) and a unit (format_filesize_kb1,205,632 KB); most do not. At the 1k–10k image scale this app targets, a bare 12345 of 89012 selected is harder to read than 12,345 of 89,012 images selected.

There is already a comma helper (core/format_utils.pyformat_count) and a status-message standard (core/status_message.pybuild_status_message, which takes a unit for the rate suffix). Neither is applied to every user-visible count: format_count is unused outside tests, and build_status_message still interpolates raw integers ({count}/{total}) with no grouping and does not put the unit next to the count itself (only in X.X unit/s).

Proposed standard

Every user-visible count (how many of something) uses:

  1. American thousands separators1,234 not 1234 (same grouping as format_count today).
  2. An explicit unit immediately after the number, with normal English pluralization (1 image, 2 images; 1 group, 2 groups).

Examples:

Context Today (typical) Standard
Status bar selection 1234 of 8901 selected 1,234 of 8,901 images selected
Progress / status message Scanning: 1500/12000 (12.3 items/s; 14:10 remain) Scanning: 1,500 / 12,000 images (12.3 images/s; 14:10 remain)
Confirm dialogs Send 1500 images to the system trash? Send 1,500 images to the system trash?
Dupe group list / grid F-DUPE_0004 (12) F-DUPE_0004 (12 images)
Sort-into-folders preview Beach (1500 images) Beach (1,500 images)
File size 1205632 KB / 1,205,632 KB keep 1,205,632 KB

Rates already carry a unit (unit/s); they should use the same unit noun as the count they describe (images/s, not a generic items/s, when the count is images).

In scope

All user-facing count displays, including but not limited to:

  • Status bar selection / filtered totals (main_window count label).
  • build_status_message / dialog_message progress lines and any worker that feeds them (directory scan, thumbnail generation, duplicate scan, sort-into-folders, subdir-tag generate, trash, etc.).
  • Confirm / summary dialogs (delete, untag, File Duplicate Bulk Actions, scan summaries).
  • Duplicate workbench group buttons, Dupe Grid cell captions, and similar membership counts.
  • Sort-into-folders preview rows (tagged / multi / untagged counts).
  • Toolbar badges if they show numeric counts (Duplicates / Trash).
  • File-size and other already-unitized quantities that are still missing grouping.

Implementation should go through shared helpers (format_count plus a small unit-aware wrapper, e.g. format_count(n, unit="image")1,234 images) so new UI cannot easily skip the standard. dialog_message's _BODY_STATUS_RE currently assumes ungrouped digits (\d+(?:/\d+)?) and must be updated if status counts gain commas.

Out of scope (not counts of things)

Do not add grouping or count-units to identifiers, ordinals, or non-count quantities:

  • Duplicate tag names (F-DUPE_0004, padding stays as configured).
  • Stage ordinals ([Stage 1/3 Discovering]).
  • Versions, ports, keyboard keys, percentages, timestamps / ETA (14:10).
  • Image pixel dimensions (1920×1080) unless they are presented as a count of pixels.
  • Log / debug strings not shown in the UI.

Acceptance criteria

  • A documented display standard: user-visible counts always use American thousands separators and a unit (pluralized).
  • Shared helper(s) implement that standard; call sites do not hand-roll {n} / {n:,} / ad-hoc image(s) strings.
  • Existing count surfaces (status bar, status/progress messages, confirm dialogs, dupe membership counts, sort-into preview, scan summaries, file sizes) match the standard.
  • Status-message parsing (dialog_message) still splits count / rate / item name correctly after commas are introduced.
  • Bundled user guide / DESIGN notes the standard if those docs currently show ungrouped example counts.
  • Tests cover grouping, singular/plural units, and a representative status-message round-trip.

Notes

This is a consistency / readability standard, not a new feature. Prefer one helper used everywhere over a one-off pass that will drift again.

## Problem or use case Count numbers shown to the user are formatted inconsistently. Some already include American thousands separators (commas) and a unit (`format_filesize_kb` → `1,205,632 KB`); most do not. At the 1k–10k image scale this app targets, a bare `12345 of 89012 selected` is harder to read than `12,345 of 89,012 images selected`. There is already a comma helper (`core/format_utils.py` → `format_count`) and a status-message standard (`core/status_message.py` → `build_status_message`, which takes a `unit` for the rate suffix). Neither is applied to every user-visible count: `format_count` is unused outside tests, and `build_status_message` still interpolates raw integers (`{count}/{total}`) with no grouping and does not put the unit next to the count itself (only in `X.X unit/s`). ## Proposed standard Every **user-visible count** (how many of something) uses: 1. **American thousands separators** — `1,234` not `1234` (same grouping as `format_count` today). 2. **An explicit unit** immediately after the number, with normal English pluralization (`1 image`, `2 images`; `1 group`, `2 groups`). Examples: | Context | Today (typical) | Standard | |---|---|---| | Status bar selection | `1234 of 8901 selected` | `1,234 of 8,901 images selected` | | Progress / status message | `Scanning: 1500/12000 (12.3 items/s; 14:10 remain)` | `Scanning: 1,500 / 12,000 images (12.3 images/s; 14:10 remain)` | | Confirm dialogs | `Send 1500 images to the system trash?` | `Send 1,500 images to the system trash?` | | Dupe group list / grid | `F-DUPE_0004 (12)` | `F-DUPE_0004 (12 images)` | | Sort-into-folders preview | `Beach (1500 images)` | `Beach (1,500 images)` | | File size | `1205632 KB` / `1,205,632 KB` | keep `1,205,632 KB` | Rates already carry a unit (`unit/s`); they should use the **same** unit noun as the count they describe (`images/s`, not a generic `items/s`, when the count is images). ### In scope All user-facing count displays, including but not limited to: - Status bar selection / filtered totals (`main_window` count label). - `build_status_message` / `dialog_message` progress lines and any worker that feeds them (directory scan, thumbnail generation, duplicate scan, sort-into-folders, subdir-tag generate, trash, etc.). - Confirm / summary dialogs (delete, untag, File Duplicate Bulk Actions, scan summaries). - Duplicate workbench group buttons, Dupe Grid cell captions, and similar membership counts. - Sort-into-folders preview rows (tagged / multi / untagged counts). - Toolbar badges if they show numeric counts (Duplicates / Trash). - File-size and other already-unitized quantities that are still missing grouping. Implementation should go through shared helpers (`format_count` plus a small unit-aware wrapper, e.g. `format_count(n, unit="image")` → `1,234 images`) so new UI cannot easily skip the standard. `dialog_message`'s `_BODY_STATUS_RE` currently assumes ungrouped digits (`\d+(?:/\d+)?`) and must be updated if status counts gain commas. ### Out of scope (not counts of things) Do **not** add grouping or count-units to identifiers, ordinals, or non-count quantities: - Duplicate tag names (`F-DUPE_0004`, padding stays as configured). - Stage ordinals (`[Stage 1/3 Discovering]`). - Versions, ports, keyboard keys, percentages, timestamps / ETA (`14:10`). - Image pixel dimensions (`1920×1080`) unless they are presented as a count of pixels. - Log / debug strings not shown in the UI. ## Acceptance criteria - [ ] A documented display standard: user-visible **counts** always use American thousands separators **and** a unit (pluralized). - [ ] Shared helper(s) implement that standard; call sites do not hand-roll `{n}` / `{n:,}` / ad-hoc `image(s)` strings. - [ ] Existing count surfaces (status bar, status/progress messages, confirm dialogs, dupe membership counts, sort-into preview, scan summaries, file sizes) match the standard. - [ ] Status-message parsing (`dialog_message`) still splits count / rate / item name correctly after commas are introduced. - [ ] Bundled user guide / DESIGN notes the standard if those docs currently show ungrouped example counts. - [ ] Tests cover grouping, singular/plural units, and a representative status-message round-trip. ## Notes This is a consistency / readability standard, not a new feature. Prefer one helper used everywhere over a one-off pass that will drift again.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
ai-collab/bulk-image-organizer#183
No description provided.