feat(intent): print scaffold emits a document-shaped layout, not a field dump - #6521
Merged
Conversation
…eld dump The generated standard.print now reads like a printed business document: - header row - the humanized title left, the document number right; - header data in two weighted columns (plain fields left, relation labels right) instead of one long field list; - totals as label/value COLUMNS (a weighted row - 2* spacer, labels, values, all right-aligned) so the figures align under each other - a right-aligned label:value line per total leaves the values ragged; - the emphasized total after the row, carrying its label. The scaffold/feeder placeholder contract is unchanged (same keys, new layout); the emitted template still parses with the document DSL (asserted in the test). Layout constructs are proven: a row renders as a fixed fo:table and width weights work on any row child. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
delchev
added a commit
that referenced
this pull request
Aug 4, 2026
…rry translation keys, labels land in the catalog (#6521) (#6524) On a localized generated app the per-record action buttons stayed English: the transition buttons (Void), the create-from buttons (Save as Template, Record Reminder) and the built-in Duplicate, plus the chat/upload strings. Two gaps: the catalog template missed nine defaults.* keys the views reference (T() fell back silently and downstream language catalogs never saw them), and the generated transition/generates descriptors emitted only a raw label although the renderer already supports T(action.translation.key, label). The nine keys are added to the catalog template. The descriptors now carry translation: {key: "<project>:<model>-model.actions.<name>"}; EdmIntentGenerator puts a customActionLabels map on the .model root (label derivation shared with the descriptors via IntentNaming.customActionLabel - authored label: else humanized name), and the template engine's model translate action folds it into the generated en catalog's actions section. IntentEngineIT locks both halves: the generate-action descriptor carries the model-catalog key and the en catalog carries the actions section (green locally); engine-intent 300/300 unit tests. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
delchev
added a commit
that referenced
this pull request
Aug 5, 2026
…task labels land in the catalog, views resolve them by name (#6521) (#6531) On a localized generated app the in-record BPM task buttons (Approve, Issue, Send, ...) stayed English: the views bound the raw runtime task.name with no translation key anywhere in the chain. Since the task set is part of the process definition, everything is resolved at generation time: EdmIntentGenerator puts a processTaskLabels map (authored step name -> humanized task name) on the .model root, the translate action folds it into the en catalog's processes section, and the Harmonia template bakes the reverse (runtime name -> key) map into config.js so the six view sites translate by exact lookup - T('<project>:<tprefix>.processes.' + processTaskKeys[task.name], task.name) - with the raw name as fallback. No runtime key derivation. The sweep also localizes the remaining hardcoded chrome: the Page x / y paginators, the "New <entity>" buttons and dialog titles, every delete-confirm dialog (including the document "Delete line" dialog whose Cancel/Delete were raw), both Print language pickers, the my/partner "Select..." placeholders, the report "No data" states and the settings Language placeholder - via new catalog keys - and wires i18n into the standalone report page (App bootstrap + i18n.js + a new shell.report section in the shared en/bg shell catalogs). Also fixes a latent translator bug: the T() fallback path returned baked strings verbatim, so {{name}}-style placeholders with runtime values (Updated {{time}}, New task: {{name}}) rendered literal braces in the default language; i18n.js and the app.js stub now interpolate the fallback. IntentEngineIT locks the catalog's processes section and the baked config.js map; engine-intent 302/302 unit tests green. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The generated
standard.printscaffold renders every header field as one long list and every total as a right-alignedlabel: valuestring - so totals print ragged (values never align as a column) and the page reads as a field dump rather than a business document.Change
The scaffold now emits:
2*spacer + labels + values stacks, right-aligned) so figures align under each other, with the emphasized<total>after the row carrying its label.Contract
PrintScaffoldFeederContractTestgreen).parseDocumentassertion inPrintIntentGeneratorTest, updated to assert the new layout).writeModelFileIfAbsentsemantics unchanged - existing hand-adapted templates are never overwritten; only fresh documents get the new scaffold.🤖 Generated with Claude Code