proposal: a key of a multilingual entity is not translated - #61
Merged
Conversation
Translatability is derived from the type, so marking an entity multilingual makes every string property translatable - right for a label, wrong for a KEY: the column a determination rule matches on, the business key an arrival resolves a relation by. Translating a key breaks the match with no observable failure at all, and the model has no way to say the property is a key. Proposes `translatable: false` on a field, and holds the two matching sites to it.
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.
Adds
proposals/0030-non-translatable-key.md. Per the proposals process this PR touches no version document.What the gap is
Translatability is derived from the type: mark an entity
multilingual: trueand every string property gains a per-language value. That is right for a label and wrong for a key — the column a determination rule'smatchselects on, the business key an arrival'slookup/byresolves a relation by.A key is compared, not read. Once it is translatable, the comparison is on a moving target: the read overlay shows the translated value, saving the row from the UI writes the translated value into the stored column, and from then on the literal the intent was authored with matches nothing. Nothing fails. The posting simply never fires again in that language; the arrival's lookup resolves nothing. A rule that has silently stopped applying looks exactly like a document nobody posted.
What it proposes
translatable: falseon a field: no column in the translation table, never overlaid on a read, read as stored in a report column, and refused in a translation seed. Defaulttrue, so an existing model is unchanged.And, because the property becomes declarable, the two matching sites can be held to it: a determination rule's
matchcolumn and a lookup'sbyfield must not be translated, and an intent that matches on a translated property is an authoring error naming the marker.Deliberate edge rules: the marker is refused where it cannot mean anything (a non-multilingual entity, a non-string property) rather than accepted and ignored — a marker that reads as protection but is not there is worse than none.
Carries
Specification text,Anchor(Multilingual data > Data, after the report normative block) and theDSL indexrow, so the release fold is mechanical.Implementation: eclipse-dirigible/dirigible#6545 (platform PR eclipse-dirigible/dirigible#7038).