MessageCatalogue.debug drops UserMessage args, unlike the unresolved-key fallback #51
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
iterative-works/support#51
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
MessageCatalogue.debugdrops aUserMessage's arguments, so a value passed only as a messageargument is invisible in any test that runs on the debug catalogue.
core/shared/src/main/scala/works/iterative/core/MessageCatalogue.scala:82-86:Why this is an omission, not a design
The missing-key fallback in the same trait already renders the arguments:
MessageCatalogue.applyends in.getOrElse(id.toString())UserMessage.toStringiss"${id}[${args.mkString(", ")}]"(UserMessage.scala:10-11)So an unresolved key renders
plan.kola.lhuta[30], whiledebugrendersplan.kola.lhutaforthe same message. The debug catalogue is strictly less informative than the fallback path, for
no stated reason. Both exist to show the reader a key rather than prose; only one of them keeps the
data.
Consequence for callers
A view spec running on
MessageCatalogue.debugcannot assert anything about a value that reachesthe page only as a message argument. Callers work around it by rendering the value as a separate
sibling node and giving the label key no
%sat all — which then constrains the i18n bundle(the label and its value can no longer be reordered by translation) purely because of a testing
artifact.
Observed in medeca-modul-poptavky (MEDECA-478): three date-carrying keys
(
plan.kola.zahajeno,.ukonceno,.obnoveni) had to be written without%sso that a speccould assert the ordering of dates across three cards.
Proposed fix
This makes
debugconsistent with the unresolved-key fallback and removes the caller-sideworkaround entirely.
Compatibility note
Specs that assert a debug string by exact equality on a key that carries arguments would change
(
"a.b"becomes"a.b[30]").contains-style assertions are unaffected, since the key remains aprefix. Worth a scan of downstream projects before merging.
Provenance: MEDECA-478 lessons triage, L34.