Translations — every visible name in the product

Almost nothing the operator reads is stored on the configuration row. A cover, a factor, a factor value, a UI group, a validation warning — each holds a DESCR_LINK, and the text lives in the message tables. Configure a product and skip this, and the UI renders raw keys. No stage owned this explicitly before; it is S3's, and S5 sweeps it.

Provenance and status. From the PC 9951 run on the Ablera dev database, 31.08.2026 (Product Configurator § SRC, full text in the extract) — except the customer-estate counts in § 1 and § 3 (22 LABEL rows on PROD; ~1,000 literal value labels per environment, measured 02.09.2026), which carry their own dates.

1. The chain

F <config row>.DESCR_LINK → SRD_IPROD.SR_MESSAGES.MSG_ID → SR_MESSAGES_LNG, one row per language.

F DESCR_LINK is a message code, not a numeric id — MSG_ID is a readable string that the configurator chooses. This trips anyone expecting a foreign key to a sequence. SR_MESSAGES holds the key, its type and a fallback text; SR_MESSAGES_LNG holds the text per language.

F MSG_TYPE distinguishes ordinary labels from errors and warnings. MESSAGE is the type for product-configuration labels — it is the overwhelming default, and LABEL is rarer than its name suggests (Product Configurator § A-5 measures 22 rows of it on PROD).

P Creating a label is three writes in order: the SR_MESSAGES row with a fallback text; one SR_MESSAGES_LNG row per language; then DESCR_LINK on the configuration row. Because the lookup tables' own DESCR_LINK is a foreign key, the label precedes the row that points at it (Write Envelopes § 7).

2. Which languages a product owes

F ⚠ Do not assume English. SR_MESSAGES.MSG is a fallback, not a translation, and the languages actually maintained are a property of the deployment, not of the product. The maintained set is the one already carrying comparable row counts in SR_MESSAGES_LNG; the long tail is noise.

P So the language set is a measured, dated convention per customer — the same shape as the other counted conventions of Product Configurator § A-19, read by the estate prober at plug-in time and carried in the Whitelabel Catalogue. A product translated into only one of them is half-configured for everyone else, and the S5 sweep says so rather than passing.

3. Where DESCR_LINK appears

F Not only on covers: PR_BASIC_PRODUCT_NAMES, PR_BASIC_COVER_NAMES, PR_PRICING_FACTOR_VALUES, PR_PRICING_FACTOR_DEPENDENT (a dependent value carries its own label), LBRR_LIMIT_RESTRICTIONS (the violation warning the operator reads), and on the factor itself as UI_GROUP_DESCR_LINK and UI_HELP_DESCR_LINK.

F ⚠ PR_PRICING_FACTOR_VALUES and PR_PRICING_FACTOR_DEPENDENT each carry both a literal PRICING_FACTOR_VALUE_NAME and a DESCR_LINK. The literal is not translated. Use it only for values that are the same in every language — a number, a code; anything a person reads needs the link. (On the customer estate the literal is in wide use as a label — ~1,000 value rows per environment — so the SR_MESSAGES join is a validity test for new rows only — measured on the customer estate 02.09.2026, Stage IPAL § PF-8.)

4. Two silent failures

F A missing translation does not error. Labels pointing at a DESCR_LINK with no SR_MESSAGES_LNG row exist in live data today; nothing complains, and the operator sees the fallback or the raw key. So "the UI rendered" is not evidence the labels are right — they are read, in each maintained language.

F ⚠ Cloning copies the pointer, not the text. A cloned cover points at the source product's message. It renders correctly and is wrong: the new product displays the donor's wording, and editing that message changes both. New labels need new codes.

P This is a hole in the donor comparison of Configuration Module § 5, which is a completeness gate — a cloned label is present, well-formed and counted, and still wrong. So the donor diff is not the check for labels; the S5 label sweep is, and it asserts three things per configuration row: the DESCR_LINK resolves in SR_MESSAGES, a row exists in each maintained language, and the message id is not one an ancestor product already points at.

Challenges

• P Whether the label sweep runs as part of S5 or as a standing configuration.verifier check — answered 04.09.2026 (D137): translations are a responsibility, not a stage. One skill (the route / label / endpoint check, Agents Memory and Skills § 10) runs the three assertions above; the Serdica stage agent holds the responsibility by default (configure.responsibilities.translations, Whitelabel Catalogue § 1) and completes the missing languages as one of its writes; the verifier re-runs the same skill read-only at H3 and refuses the sign-out while a maintained language is missing. A plug-in may move the responsibility to another stage; nothing else changes, because the assertions live in the skill and not in either agent. What is measured with the first full-set case is only how many keys S5 finds that S3 did not write.

Related: Stage IPAL · Stage Serdica · Shared Vocabulary · Write Envelopes