[Enhancement]: Standardize all count displays with thousands separators and units #183
Labels
No labels
Kind/Bug
Kind/Feature
Priority/High
Priority/Medium
Reviewed/Confirmed
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
ai-collab/bulk-image-organizer#183
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 bare12345 of 89012 selectedis harder to read than12,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 aunitfor the rate suffix). Neither is applied to every user-visible count:format_countis unused outside tests, andbuild_status_messagestill interpolates raw integers ({count}/{total}) with no grouping and does not put the unit next to the count itself (only inX.X unit/s).Proposed standard
Every user-visible count (how many of something) uses:
1,234not1234(same grouping asformat_counttoday).1 image,2 images;1 group,2 groups).Examples:
1234 of 8901 selected1,234 of 8,901 images selectedScanning: 1500/12000 (12.3 items/s; 14:10 remain)Scanning: 1,500 / 12,000 images (12.3 images/s; 14:10 remain)Send 1500 images to the system trash?Send 1,500 images to the system trash?F-DUPE_0004 (12)F-DUPE_0004 (12 images)Beach (1500 images)Beach (1,500 images)1205632 KB/1,205,632 KB1,205,632 KBRates already carry a unit (
unit/s); they should use the same unit noun as the count they describe (images/s, not a genericitems/s, when the count is images).In scope
All user-facing count displays, including but not limited to:
main_windowcount label).build_status_message/dialog_messageprogress lines and any worker that feeds them (directory scan, thumbnail generation, duplicate scan, sort-into-folders, subdir-tag generate, trash, etc.).Implementation should go through shared helpers (
format_countplus 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_REcurrently 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:
F-DUPE_0004, padding stays as configured).[Stage 1/3 Discovering]).14:10).1920×1080) unless they are presented as a count of pixels.Acceptance criteria
{n}/{n:,}/ ad-hocimage(s)strings.dialog_message) still splits count / rate / item name correctly after commas are introduced.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.