Skip to content

feat(intent): print scaffold emits a document-shaped layout, not a field dump - #6521

Merged
delchev merged 1 commit into
masterfrom
feat/print-scaffold-layout
Aug 4, 2026
Merged

feat(intent): print scaffold emits a document-shaped layout, not a field dump#6521
delchev merged 1 commit into
masterfrom
feat/print-scaffold-layout

Conversation

@delchev

@delchev delchev commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Problem

The generated standard.print scaffold renders every header field as one long list and every total as a right-aligned label: value string - 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:

  • a header row: humanized title left, document number (documentTitle field) right;
  • header data in two weighted columns - plain fields left, to-one relation labels right (falls back to the flat section when either side is empty);
  • totals as label/value columns: a weighted row (2* spacer + labels + values stacks, right-aligned) so figures align under each other, with the emphasized <total> after the row carrying its label.

Contract

  • The scaffold/feeder placeholder contract is untouched - same keys, new layout (PrintScaffoldFeederContractTest green).
  • The emitted template still parses with the document DSL (parseDocument assertion in PrintIntentGeneratorTest, updated to assert the new layout).
  • writeModelFileIfAbsent semantics unchanged - existing hand-adapted templates are never overwritten; only fresh documents get the new scaffold.
  • engine-intent unit suite: 300 tests, 0 failures.

🤖 Generated with Claude Code

…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
delchev merged commit a8895e5 into master Aug 4, 2026
10 checks passed
@delchev
delchev deleted the feat/print-scaffold-layout branch August 4, 2026 17:21
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant