docs(spec): keys of a multilingual entity are not translated - #45
Open
delchev wants to merge 1 commit into
Open
Conversation
`translatable: false` on a field, and the two matching sites held to it - a determination rule's match column and a business-key lookup's `by` field. A translated key stops matching the value the intent was authored with, with no observable failure at all. Mirrors intent-specification proposal 0030.
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 the
translatable: falsemarker to Data, seeds & naming → Multilingual data as its own subsection ("Keys are not translated"), plus the reference-table row.On a
multilingual: trueentity every string property is translatable, because translatability is derived from the type. That is right for a label and wrong for a key — the column a determination rule matches on, the business key an arrival's lookup resolves a relation by. Once a key is translatable the comparison is on a moving target: the read overlay shows the translated value, saving the row writes it into the stored column, and the literal the intent was authored with matches nothing from then on. Nothing fails; the rule just stops applying.The normative block states the marker's semantics (no translation-table column, never overlaid, read as stored in a report column, refused in a translation seed, default
true), that it is refused where it cannot mean anything, and that a rule's match column and a lookup'sbyfield must not be translated.npx vitepress build docsis clean.Tracks intent-specification#61 (proposal 0030) — leave open until that proposal is accepted. Implementation: eclipse-dirigible/dirigible#7038.