fix(harmonia): print data in the chosen print language, not the UI locale (#6945) - #6946
Merged
delchev merged 1 commit intoAug 27, 2026
Conversation
…cale (eclipse-dirigible#6945) The Harmonia document/manage Print flow picked the template folder by the chosen print language (labels came out correctly) but fetched the print data from the generated PrintFeeder with the UI locale as Accept-Language. Since the generated repositories overlay multilingual values from Accept-Language, the nomenclature VALUES (Payment Method, Sent Method, Status, ...) rendered in the UI locale while the template rendered in the print language - the two halves of the document disagreed. Pin the feeder GET's Accept-Language to the chosen print language so the multilingual overlay resolves data in the same language as the template: - api.js: request() honors an opt-in { language } per-call override; absent it, the Region & Language store applies as before. - document-page / form-page print feeder fetch passes { language: lang }. Also refresh the engine-document guide, which still described the pre-feeder "client supplies the data" design. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
delchev
pushed a commit
that referenced
this pull request
Aug 27, 2026
…he render language (#6947) (#6948) * fix(intent): server-side PDF renders resolve nomenclature values in the render language (#6947) The two server-side PDF paths - the immutable snapshot minted on issue and the notify `attach: print`/`recordPrint`/`report` PDF mailed to the recipient - pick their `.print` template by the mint language but built the `{document, items}` payload by calling the generated `<Master>PrintFeeder` (or the report repository) in-process. The multilingual overlay a generated repository applies reads `User.getLanguage()`, i.e. the request's Accept-Language - and a BPM service task has no request. So nomenclature values (Payment Method, Sent Method, Status, any multilingual nomenclature) fell back to the default language while the template rendered in the mint language (a Bulgarian invoice reading "Bank transfer" / "ISSUED"). This is the server-side half of #6945 (fixed client-side in #6946), which is out of that PR's scope because there is no header to pin. Fix: a thread-bound language override in `UserFacade`, preferred by `getLanguage()` over the absent header, set by each render around the feed/render and cleared in a finally so a pooled worker thread never leaks it. The feeder's HTTP `@Get("/{id}")` path is untouched; all reads still go through repositories. - api-security: `UserFacade.setLanguage/clearLanguage` + override in `getLanguage` - api-modules-java: expose `sdk.security.User.setLanguage/clearLanguage` - templates: `Snapshot`, `Send`, `Notification` wrap feed/render (each attach branch) - tests: `UserFacadeLanguageOverrideTest`; `IntentEmissionCoverageIT` asserts the set/clear on every attach branch - docs: engine-intent guide mint-language bullet Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: re-trigger checks (flaky EdmModelRoundTripIT timeout) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(intent): transition-notify PDF render binds the render language, and the extracted render local is byte[] (#6947) The #6947 render-language fix wrapped the server-side PDF render in a thread-bound `User.setLanguage`/`clearLanguage` in `Send`, `Notification` and `Snapshot`, but missed `Transition.java.template` - the transition `notify` block is a separate render path with its own three render sites (`attach: print` / `recordPrint` / `report`). So a transition-driven render (the `SendBill` case, generated as `SendBillTransition.java`) still resolved nomenclature values in the default language while the template rendered in the mint language. The same fix also introduced a latent compile error it never surfaced: extracting the render into a local typed it `String data`, but `sdk.print.Print.render` returns `byte[]`. `document.put("data", render(...))` compiled because `put` takes `Object`; a typed `String` local does not (`javac: byte[] cannot be converted to java.lang.String`). It broke the whole emission client-Java batch - every runtime endpoint 404'd - but was masked because `IntentEmissionCoverageIT` failed on the missing-Transition content assertion before it ever compiled the batch. - Transition.java.template: bind the language around all three render sites - Send/Notification/Transition: `String data` -> `byte[] data` (8 sites) (Snapshot was already `byte[] pdf`) - IntentEmissionCoverageIT now passes fully (content + runtime enforcement) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <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
2 participants
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
Fixes #6945.
Printing a document (or a record from the manage form) in a language different from the current UI language produced a PDF whose labels were in the chosen print language but whose nomenclature values (Payment Method, Sent Method, Status, ...) were in the UI locale. The two halves of the document disagreed — e.g. a Bulgarian Sales Invoice template (ФАКТУРА, ПАДЕЖ) still reading "E-mail" / "Bank transfer" / "SENT".
Root cause
The Harmonia Print flow has two language selectors that were not kept in sync:
langis passed asPOST /services/print/{entity}?lang=bg, which selects the CMS template folderTemplates/<Entity>/Print/bg/. ✅{document, items}payload is fetched from the generated…PrintFeeder/{id}endpoint first. The feeder loads each related nomenclature through its generated repository, which overlays translations viaTranslatorusingUser.getLanguage()→ the request'sAccept-Languageheader.The feeder is fetched through the shared
App.services.api.get(...), which always setsAccept-Languageto the UI locale store (codbex.harmonia.language), never the print-dialoglang. So the data translated to the UI language while the template was in the print language.Fix
Pin the feeder GET's
Accept-Languageto the chosen print language, so the multilingual overlay resolves data in the same language as the template — using the mechanism the rest of the platform already uses.application-coreservices/api.js:request()honors an opt-in{ language }per-call override; absent it, the Region & Language store applies exactly as before (backward compatible).document-page.js.templateandform-page.js.template: the print feeder fetch passes{ language: lang }.engine-documentguide, which still described the pre-feeder "client supplies the data" design.Scope / notes
attach: print/reportinSend.java/Notification.java) calls the feeder in a background listener where there is no request-scopedAccept-Language; it selects the template language via an expression but the feeder data stays in the base language. That is the same bug class but a different (in-process, thread-local) fix and is intentionally out of scope here.Verification
Manual (no JS test harness): generate an app with a multilingual nomenclature and a
bgprint template, keep UI = English, print → Bulgarian; the nomenclature values now render in Bulgarian ("Банков превод", "Изпратена"). English-UI/English-print is byte-identical to before.Reminder:
api.jsis bundled into the fat jar — a locally running instance needsapplication-core+build/applicationrepackaged and a restart to reflect the change; target apps need regeneration to pick up the template edits.🤖 Generated with Claude Code