When an approved answer label becomes a different data type
A bilingual form can contain the right words in its content file and still publish the wrong choices. The file format is part of that journey. A word intended for a reader may have a second meaning to the program loading it.
This guide follows a fictional supplier enquiry with English and Serbian Latin wording. The content owner has approved a question asking whether sales may propose a different finish. The approved choice labels are “Yes” and “No” in English, and “Da” and “Ne” in Serbian. The saved answer codes are allow and decline; those codes are deliberately separate from the visible words.
The example concerns typed content loading. It does not establish that those short labels are sufficient for another business's question, or replace review of the complete Serbian sentence and its commercial meaning.
Keep the source, loaded value and public label separate
The fictional publishing application loads a YAML content file with PyYAML 6.0.3 using safe_load and its default implicit resolvers. Its renderer expects human-readable labels, but the existing release check examines only whether the keys exist.
The English file contains an unquoted No. After loading, the value is the Boolean False, not the string No. The corresponding Serbian Ne remains a string. The renderer's generic value conversion consequently publishes “false” for the English negative choice. The answer code is still decline, but the customer no longer sees the approved wording.
| Surface | English negative choice | Serbian negative choice |
|---|---|---|
| Approved wording | No | Ne |
| Original plain YAML scalar | No |
Ne |
| Loaded value and type | False, Boolean |
Ne, string |
| Faulty public label | false | Ne |
| Answer code | decline |
decline |
The comparison localises the defect before rendering. The stored customer answer has not been mistranslated, the browser has not changed character encoding and the Serbian file has not proved the English file correct. The two words follow different implicit type rules in this particular loader.
Verify the actual content-file contract
YAML 1.1's Boolean type definition includes forms such as yes, no, on and off. Later YAML conventions differ: the YAML 1.2 change notes describe a narrower Boolean interpretation in the core schema. A file extension alone therefore does not identify what an installed loader will do.
The investigation records the actual library version, loading method and resulting types. It also checks the English positive label: unquoted Yes loads as a Boolean in this environment. Fixing only the visible negative option would leave the same defect in its neighbour.
The PyYAML documentation provides the relevant scalar and loading context. A real project must inspect its own processor and configuration. This example is not a claim that every YAML implementation interprets these values identically.
Choose a bounded correction
The team considers changing the loader or migrating the whole configuration format. Either could have wider consequences because the same application also reads settings that are intentionally Boolean. Neither is necessary to correct these content labels.
The selected repair keeps the inspected loader and makes textual labels explicit quoted strings. The negative entry becomes decline: "No"; the positive entry becomes allow: "Yes". Serbian labels are also represented explicitly as strings so the content convention is consistent. This is a serialization decision, not a translation of False back into a guessed word after loading.
A release check now requires every label in this defined choice group to be a nonempty string. An unexpected Boolean stops that content release with a useful field reference. It does not disappear silently, inherit a different language's label or become the word “false” on the public form.
Follow the corrected choice into the request
The reviewer opens both language versions in the isolated fictional preview. The English form shows the approved complete question with “Yes” and “No”; the Serbian form shows its approved question with “Da” and “Ne”. Selecting the negative choice in either version submits the stable answer decline for request Q-71.
The receiving review screen describes that answer as a refusal to authorise an alternative-finish proposal under the fixture's agreed question. It does not reinterpret a language label as the business code. A separate positive request Q-72 carries allow, making the contrary result visible.
Reloading the content files preserves their string types and displayed labels. The reviewer records the file revision, loader version, two language views and the receiving values. That evidence establishes the repaired content path for this question; it does not approve every translation in the application.
Keep the controls that could reveal an overbroad fix
| Control | Required result |
|---|---|
Unquoted No reintroduced into a label field |
Release check rejects the wrong type before publication |
Genuine configuration enabled: false |
Remains a Boolean setting; no blanket conversion to text |
Approved explanatory label "false" in a separate example |
Remains the literal string, with its intended spelling |
Serbian Da and Ne labels |
Remain approved strings and retain their answer-code mappings |
| Positive answer Q-72 | Reaches allow, distinct from Q-71 |
| Missing choice label | Reported as incomplete content rather than borrowed from another language |
These checks matter because coercing every loaded value into a string would conceal the contract error. It would also blur settings and reader-facing content. The repair should preserve the distinction the application actually needs.
Make language review include the loaded result
A reviewer needs the final form as well as the source document. Include question text, choice labels, validation messages, confirmation and the receiving interpretation. Keep technical identifiers out of translation work unless their role has been explicitly discussed.
For business websites and catalogue portals, identify who approves Serbian wording and which script the audience needs. The technical team can preserve values and enforce the content schema. The nominated language and business reviewers determine whether the words express the intended decision.