spec: a report column of a multilingual entity is read in the caller's language - #25
Open
delchev wants to merge 1 commit into
Open
spec: a report column of a multilingual entity is read in the caller's language#25delchev wants to merge 1 commit into
delchev wants to merge 1 commit into
Conversation
…s language The chapter already said every read of a translatable property is served in the caller's requested language, but left open whether a report column counts as such a read - and in practice it did not, so a report grouping by a multilingual nomenclature showed the stored term beside a list showing the translated one. State it normatively, and state the boundary that makes it safe: what a report MATCHES is unaffected - its filter, its scope and any condition applied to it are evaluated against the stored, untranslated values, so translating content can never change which rows a report returns, only how they read. Co-Authored-By: Claude Opus 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
1 participant
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.
What this clarifies
The Multilingual data chapter already says that every read of a translatable property is served in the caller's requested language. It never said whether a report column counts as such a read — and a report is not an entity read at all, it is an aggregation over stored values, so an implementation could reasonably go either way.
In practice implementations went the other way, and the result is visibly wrong to a user: a report grouping by a multilingual nomenclature showed the stored term (
DRAFT) right beside a list page showing the translated one, for the same record.What it says
Two sentences of prose plus a Normative paragraph in Multilingual data → Data, and the Appendix A row:
filter:, itsscope:and any condition applied to it are evaluated against the stored, untranslated values, so translating content can never change which rows a report returns, only how they read.No new construct and no new keyword — this constrains what a conforming generator must do with the existing
multilingual:attribute.Reference implementation
Proven out in the reference implementation by eclipse-dirigible/dirigible#6750 (issue #6544): the translated column is emitted as a
COALESCEover aLEFT JOINto the entity's translation table keyed on a bound language parameter, so the fallback and the filter boundary both fall out of the SQL rather than being enforced separately. Its integration test asserts the same published report returning the translated term under one request language and the stored one under another.