Two improvements to the result box on the new page:
COLOR BY TYPE: the result box should use the semantic status colors (already defined: --ok, --err, --warn from #16). Success = --ok border/text tint, validation errors = --err, soft warnings = --warn. Currently it's monochrome regardless of outcome.
HUMAN-FRIENDLY ERROR MESSAGES: rewrite all user-facing validation errors from developer-speak to plain guidance, and map them client-side where the backend message is technical. Examples of the desired tone:
'Error: custom slug must be 1-64 chars: letters, digits, dash, underscore; must start with letter or digit' -> 'Please keep the Custom URL under 64 characters, using only letters, numbers, dashes, or underscores (starting with a letter or number).'
slug taken -> 'That Custom URL is already taken. Try another.'
content empty -> 'Write or paste something first.'
content too large -> 'This paste is too large. The limit is 5 MB.'
expiry out of range -> 'Please pick an expiry between 1 minute and 1 year.'
password too short / rate limited -> similarly plain phrasing ('Too many tries. Wait a minute and try again.')
Implementation: keep technical detail in API responses for API consumers, but the new-page JS translates known backend error patterns into the friendly strings above (a small error-message map, fallback to a generic 'Something went wrong. Please try again.' for unknown errors). Result box gets an icon or colored left border matching the status color.
Audit ALL backend validation messages (main.go, cans.go, internal/api) and either rewrite them plainly or add a machine-readable error code the UI can map (preferred: error code like 'slug_taken' + human message). Update docs/API.md error section.
Two improvements to the result box on the new page:
1. COLOR BY TYPE: the result box should use the semantic status colors (already defined: --ok, --err, --warn from #16). Success = --ok border/text tint, validation errors = --err, soft warnings = --warn. Currently it's monochrome regardless of outcome.
2. HUMAN-FRIENDLY ERROR MESSAGES: rewrite all user-facing validation errors from developer-speak to plain guidance, and map them client-side where the backend message is technical. Examples of the desired tone:
- 'Error: custom slug must be 1-64 chars: letters, digits, dash, underscore; must start with letter or digit' -> 'Please keep the Custom URL under 64 characters, using only letters, numbers, dashes, or underscores (starting with a letter or number).'
- slug taken -> 'That Custom URL is already taken. Try another.'
- content empty -> 'Write or paste something first.'
- content too large -> 'This paste is too large. The limit is 5 MB.'
- expiry out of range -> 'Please pick an expiry between 1 minute and 1 year.'
- password too short / rate limited -> similarly plain phrasing ('Too many tries. Wait a minute and try again.')
Implementation: keep technical detail in API responses for API consumers, but the new-page JS translates known backend error patterns into the friendly strings above (a small error-message map, fallback to a generic 'Something went wrong. Please try again.' for unknown errors). Result box gets an icon or colored left border matching the status color.
Audit ALL backend validation messages (main.go, cans.go, internal/api) and either rewrite them plainly or add a machine-readable error code the UI can map (preferred: error code like 'slug_taken' + human message). Update docs/API.md error section.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Two improvements to the result box on the new page:
COLOR BY TYPE: the result box should use the semantic status colors (already defined: --ok, --err, --warn from #16). Success = --ok border/text tint, validation errors = --err, soft warnings = --warn. Currently it's monochrome regardless of outcome.
HUMAN-FRIENDLY ERROR MESSAGES: rewrite all user-facing validation errors from developer-speak to plain guidance, and map them client-side where the backend message is technical. Examples of the desired tone:
Implementation: keep technical detail in API responses for API consumers, but the new-page JS translates known backend error patterns into the friendly strings above (a small error-message map, fallback to a generic 'Something went wrong. Please try again.' for unknown errors). Result box gets an icon or colored left border matching the status color.
Audit ALL backend validation messages (main.go, cans.go, internal/api) and either rewrite them plainly or add a machine-readable error code the UI can map (preferred: error code like 'slug_taken' + human message). Update docs/API.md error section.