If you search for YAML block scalar QA, YAML literal vs folded text, YAML chomping indicator, or | vs > in YAML, the problem is structural presentation with real downstream effects. YAML block scalars let long strings span multiple physical lines, but literal style and folded style do not preserve those lines in the same way, and the - or + chomping indicators change what happens to the final newline and trailing blank lines.
A fast localization QA workflow therefore treats YAML block-scalar style as part of the serialization contract around translated text. A translator can write correct prose and still change a message by converting | to >, altering indentation, removing a chomping indicator, or reflowing a preformatted example that was meant to keep exact line breaks.
This guide explains how people translate quickly by validating YAML literal scalars, folded scalars, indentation indicators and chomping behavior. It covers |, >, |-, |+, >-, >+, indentation, blank lines, multiline UI copy, Markdown, code examples, emails, CAT/TMS round trips, YAML serializers, CI and safe remediation.
The owner job is distinct from Mixed Line-Ending QA and YAML Anchors & Aliases QA. Mixed Line-Ending QA owns file-level LF/CRLF consistency. Anchors & Aliases QA owns shared-node reuse. Block Scalar & Chomping QA owns how one YAML string’s physical lines become the scalar value the application receives.
1. Literal Style Uses the | Indicator
YAML literal block scalars begin with the vertical bar indicator. Indented line breaks inside the scalar are preserved as line-feed characters in the resulting string.
This is useful for code, addresses, poetry, templates and content where line structure matters. Do not replace literal style with folded style merely to make the file shorter. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
2. Folded Style Uses the > Indicator
YAML folded block scalars begin with the greater-than indicator. Ordinary single line breaks are generally folded into spaces while blank and more-indented lines preserve stronger breaks.
This makes long prose easier to wrap in source files without necessarily inserting user-visible newlines. The translator should know whether line wrapping is editorial or semantic. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
3. Literal and Folded Can Render Different User Text
Two YAML blocks with identical visible physical lines can construct different strings depending on | or >. A UI paragraph can therefore gain or lose line breaks even when the words are unchanged.
Compare parsed scalar values rather than raw file appearance. Serialization style can change the delivered message shape. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
4. Default Chomping Is Clip
If no + or – chomping indicator is present, YAML uses clip behavior. The final line break is preserved while trailing empty lines are removed.
This means a block can end with one newline even when the editor view appears to end cleanly. Final-newline semantics deserve explicit tests when consumers care. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
5. Strip Uses the – Indicator
The strip chomping indicator removes the final line break and trailing empty lines. Forms such as |- and >- therefore create strings without a terminal newline.
That can matter in command templates, emails, shell fragments or concatenated text. Do not remove the dash as cosmetic punctuation. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
6. Keep Uses the + Indicator
The keep chomping indicator preserves the final line break and all trailing empty lines. Forms such as |+ and >+ can therefore carry multiple trailing newlines into the runtime value.
This is occasionally intentional and often surprising. QA should compare the parsed result with the intended consumer behavior. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
7. Chomping Is Not the Same as Folding
Folding controls internal line breaks in a folded scalar; chomping controls the final break and trailing empty lines. A block can be folded and stripped, literal and kept, or use other combinations.
Do not describe >- merely as ‘folded’ and forget the missing final newline. Two independent controls exist. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
8. Indentation Determines Scalar Scope
Block scalar content is identified by indentation relative to the containing structure. A line indented too little can end the scalar and become a new YAML node.
A line indented too much may become more-indented content with different folding behavior. Indentation is syntax, not visual preference. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
9. Explicit Indentation Indicators Can Lock Scope
YAML allows a numeric indentation indicator in the block header. This can help when the first content line is empty or begins with significant spaces.
Changing the indicator changes how many leading spaces are removed from each content line. Do not alter it without parsing the result. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
10. More-Indented Lines Are Preserved Differently in Folded Scalars
Folded style does not simply replace every newline with a space. More-indented lines can preserve line breaks and behave like preformatted subblocks.
This allows mixed prose and code-like content inside one folded scalar. QA should test actual parser output instead of applying a simple mental rule. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
11. Blank Lines Affect Folding
Blank lines create paragraph-like separation in folded scalars. Several physical line breaks can become fewer logical line breaks according to YAML folding rules.
Manual reflow can therefore change paragraph boundaries. Translators should edit content, not normalize blank lines by habit. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
12. Whitespace Is Content Inside Literal Scalars
Literal block scalars preserve indented content characters, including spaces and tabs that belong to the scalar. Formatting-sensitive text can depend on them.
A source formatter that trims trailing or leading spaces can change the payload. Use format-aware serializers and tests. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
13. There Is No Backslash Escape Processing in Literal Block Content
Literal block scalars are not double-quoted scalars. Backslash sequences such as \n are ordinarily literal backslash+n characters unless a downstream consumer interprets them later.
Do not convert raw line breaks to escape sequences automatically. Know which parser owns each layer. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
14. Folded Block Content Is Also Not a Double-Quoted String
The folded style changes line folding but does not activate the escape semantics of YAML double quotes. A backslash remains ordinary content in the scalar.
This matters for regex, Windows paths and code snippets. Scalar style and escape syntax are separate concepts. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
15. Multiline UI Copy Needs a Defined Policy
Some products store long UI messages in folded YAML blocks so maintainers can wrap lines without changing rendered prose. Others use literal blocks because visible line breaks are intentional.
Document the intended style by field or namespace. Do not let translators choose arbitrarily per string. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
16. Email Templates Often Need Literal Newlines
Plain-text email bodies frequently depend on deliberate paragraph and signature line breaks. Literal style can preserve those structures clearly.
A folded conversion may collapse them into spaces. Render a real email sample before approving the serializer. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
17. Markdown Inside YAML Needs Two Layers of Thinking
A YAML block can contain Markdown that will later be parsed by a Markdown renderer. YAML determines the string’s line breaks before Markdown interprets them.
Changing | to > can alter Markdown paragraphs, lists or code fences. Test both the YAML parse and the Markdown render. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
18. Code Blocks Should Usually Stay Literal
Source-code samples, shell commands and configuration fragments often require exact physical lines. Literal block scalars are a natural fit.
Folded style can join lines and make examples invalid. Protect code-like content during translation extraction. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
19. Addresses and Poetry Need Intentional Line Preservation
Postal addresses, verse, song-like layout and formatted notices can use line boundaries as meaning or presentation. Literal style can preserve them without visible escape syntax.
Do not normalize them into prose paragraphs. Reader function determines the correct scalar style. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
20. Long Prose Can Benefit From Folded Style
Policy text, help paragraphs and descriptions can remain readable in YAML source when wrapped across physical lines with >. The runtime value can still become ordinary prose with spaces.
This reduces editor line length without forcing user-visible line breaks. But only if the folding rules match the desired result. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
21. Localization Can Lengthen Lines Dramatically
A source folded scalar wrapped neatly at 80 columns may expand in the target language. Translators or formatters may rewrap physical lines.
That is usually safe only when the field intentionally uses folded style for prose. Literal fields must not be rewrapped casually. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
22. Automatic Formatters Can Change Physical Wrapping
YAML formatters may reindent or reflow block scalars differently depending on configuration. A good formatter should preserve scalar semantics, but bugs or style conversions can still occur.
Run parser-based before/after comparisons. Do not trust pretty output without semantic diffing. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
23. Serializers Can Change Scalar Style While Preserving Value
A YAML serializer may emit a quoted scalar instead of a block scalar, or switch block styles while preserving the resulting string. If the application only cares about data value, this can be harmless.
If human maintainability or exact lexical style matters, configure the serializer accordingly. Separate semantic fidelity from presentation fidelity. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
24. CAT Tools May Flatten Multiline Scalars
A localization filter can expose one logical string without showing whether YAML used | or >. That protects translators from syntax but can hide layout intent.
Provide context or field rules such as ‘preserve paragraph breaks.’ Round-trip export must restore equivalent scalar value. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
25. CAT Tools May Expose Physical Lines Separately
Weak YAML import workflows can split one scalar into multiple translation segments. That encourages translators to alter line structure independently.
Use a YAML-aware filter where possible. Physical lines are not necessarily separate messages. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
26. Spreadsheet Export Can Lose Chomping Information
Flattening YAML strings into spreadsheet cells can preserve visible text while losing whether the final newline existed. On rebuild, every multiline field may get a different terminal-newline policy.
If final newlines matter, store that metadata or regenerate deterministically. Round trips must preserve more than what a cell visually shows. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
27. Final Newlines Can Affect Concatenation
A string with a terminal newline concatenated with another block behaves differently from one without it. This can produce missing or doubled line breaks in generated messages.
Chomping indicators therefore can affect runtime composition. Test concatenated output, not only isolated strings. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
28. Final Newlines Can Affect Shell and Script Payloads
Some script interpreters or command templates expect a newline at the end of a generated file; others do not care. Localization should not decide that requirement blindly.
Keep technical payloads protected or explicitly documented. Chomping is infrastructure when strings become files. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
29. Trailing Blank Lines Can Affect Rendering
A kept block with extra trailing lines may create unexpected vertical space in Markdown, email, preformatted HTML or logs. The blank lines can be invisible in YAML review.
Render the consumer surface. Whitespace at the end can still be user-visible. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
30. Trailing Blank Lines Can Affect Tests and Hashes
Exact-string tests, snapshot tests and checksums can distinguish one newline from two. A translation edit that changes only chomping can therefore fail builds.
This is often a useful signal. Do not silence exact-string tests without understanding the intended payload. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
31. Leading Blank Lines Need Care
A block scalar can begin with blank content lines. Formatters and spreadsheet conversions may remove them.
If the content begins with deliberate spacing, test parser output explicitly. Leading whitespace can carry structure in templates and code examples. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
32. Indentation Errors Can Move Text Out of the Scalar
One under-indented target line can become a YAML key or sibling node instead of string content. The parser error may appear several lines later.
Validate YAML before linguistic sign-off. Structural parsing should fail fast. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
33. Over-Indentation Can Change Folded Semantics
A more-indented target line inside > can preserve line breaks differently from surrounding prose. An accidental extra space can therefore change output while the YAML remains valid.
Compare decoded scalar value after reindentation. Valid syntax does not guarantee identical text. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
34. Tabs in Indentation Are High Risk
YAML indentation is space-sensitive and tab handling is restricted. A pasted tab can make the file fail or behave unexpectedly.
Use editors that reveal tabs and format-aware linting. Do not align YAML indentation with tabs. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
35. Literal Tabs Inside Content Are Different
A tab that belongs inside scalar content is not the same as a tab used for YAML indentation. The consumer may legitimately need the content tab.
Context determines whether it is data or syntax. Raw Control Character QA can complement this owner. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
36. Quoted Scalars Can Be Safer for Short Multiline-Free Values
Not every string needs block scalar style. Short values without intentional line structure can often use plain or quoted YAML scalars more predictably.
Do not convert all translations to block scalars merely for visual consistency. Choose style based on content needs. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
37. Literal Style Is Not ‘More Accurate’ Than Folded Style
Both styles are standard YAML representations with different semantics. The correct choice depends on whether physical source lines should become runtime line breaks.
Avoid moral labels such as literal=good, folded=bad. Structure should reflect intent. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
38. Folded Style Is Not a Translation Summarizer
The word folded can sound like content is being summarized or compressed. It only describes line-folding behavior.
Do not rewrite prose because the scalar uses >. Translate the message normally, preserving the intended logical paragraphs. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
39. Chomping Indicators Should Be Locked Tokens
The characters -, + and any indentation digit in the block header are YAML syntax. Translators should not edit them accidentally.
CAT filters can protect them or keep them outside the translation surface. Technical tokens need technical ownership. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
40. Project Style Guides Can Standardize Scalar Choices
A project may require | for templates, > for prose and quoted scalars for short labels. That convention improves maintainability and reduces review debate.
Document it in source-authoring guidance. Consistency upstream simplifies every locale. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
41. Source Preflight Should Inventory Block Scalars
Count how many translatable values use |, >, chomping and explicit indentation. Identify high-risk code or rich-text payloads.
Use that inventory to choose CAT extraction strategy. A few minutes of preflight can prevent many round-trip defects. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
42. Version Diffing Should Compare Parsed Values
A raw diff can show many rewrap changes in folded blocks even when the resulting string is identical. A semantic diff can confirm whether the value changed.
Keep both views when lexical style matters. Parsed comparison reduces false alarms. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
43. Semantic Diffs Can Also Expose Invisible Changes
A block that looks almost unchanged can parse to a string with a missing final newline or extra blank line. Compare escaped decoded values in technical QA reports.
This makes whitespace visible. Diagnostics should reveal the actual payload. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
44. Golden Fixtures Should Cover All Chomping Modes
Maintain samples for |, |-, |+, >, >- and >+ with trailing blank lines. Round-trip them through editors, CAT tools and serializers.
Assert both raw validity and parsed string value. This catches regressions after tooling changes. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
45. Golden Fixtures Should Include More-Indented Lines
Folded blocks containing an indented code sub-block exercise the nuanced folding rules. Use one example in regression tests.
Simple one-line prose cannot prove the pipeline handles real block scalars. Edge cases should be deliberate. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
46. CI Can Parse and Compare Scalars
Automated checks can load YAML and compare selected source/target field shapes or expected newline invariants. Do not hard-code exact source/target language equality.
Validate structural rules such as ‘this field must end with newline’ or ‘this namespace is single-line.’ Technical invariants are automatable. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
47. CI Can Lint Chomping Policy
If certain generated files require |- or |+, source linting can check the lexical block header too. This is a project convention above YAML semantics.
Keep the rule narrow to fields where it matters. Presentation style should only block builds when it has real value. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
48. Release QA Should Render High-Risk Multiline Fields
Parse the shipping YAML, then feed email bodies, Markdown, templates or preformatted content into their real consumer. This validates the final semantic effect of folding and chomping.
Raw YAML validation alone cannot prove the user experience. End-to-end testing closes the loop. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
49. Do Not Repair Chomping by Adding Visible Characters
Adding spaces or literal \n text to compensate for a missing terminal newline creates a second layer of confusion. Fix the YAML scalar header or serializer instead.
Language content should not encode around a structural bug. Repair the right layer. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
50. Do Not Reflow Literal Content Automatically
A formatter or translator can make a code sample more visually tidy and unintentionally change the payload. Literal means the physical lines are content.
Treat them as intentional unless the author approves a rewrite. Whitespace can be meaning. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
51. Do Not Freeze Folded Physical Wrapping Unnecessarily
If > is intentionally used for prose, translators can usually rewrap physical lines while preserving paragraphs. Locking every source line one-for-one can make target editing awkward.
Preserve logical content rather than source column width. Folding exists partly to separate source wrapping from runtime prose. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
52. Block Scalar QA Complements Line-Ending QA
YAML normalizes line breaks at the parsing level, while repository files still have LF/CRLF conventions. One owner protects parsed string semantics; the other protects file-level eol policy.
Run both when multiline resources are versioned. Similar terminology hides different layers. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
53. Block Scalar QA Complements Escape QA
A backslash+n inside a literal or folded block is ordinary text unless a downstream parser interprets it. Escape-Sequence QA owns serialized escapes in formats that use them.
Do not convert between raw YAML newlines and escape sequences blindly. Parser boundaries matter. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
54. Block Scalar QA Complements Array/Type QA
A multiline scalar remains a scalar string even when it spans many physical lines. Do not mistake line count for array elements or structured children.
Value-Type QA should still report string. Presentation is not data kind. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
55. Fix Repeated Problems in the Serializer
If one export tool repeatedly changes > to | or strips final newlines incorrectly, repair that tool or configuration. Do not train translators to patch headers manually after every job.
Systemic lexical drift needs a systemic owner. Localization QA should remove recurring technical chores. The safe workflow compares the parsed scalar value with the intended runtime text instead of judging only the YAML’s visual layout.
A practical QA step is to parse the field, show its decoded line breaks in escaped form, verify folding and final-newline policy, round-trip through the actual CAT/export pipeline, and fix scalar headers or serializers rather than changing translation wording to compensate.
Practical YAML Block-Scalar QA Workflow
Classify translatable block scalars as literal or folded according to field purpose.
Protect |, >, chomping indicators and explicit indentation indicators from translation.
Parse target values and compare decoded line breaks with intended runtime text.
Test all six common combinations: |, |-, |+, >, >-, >+.
Round-trip code samples, Markdown, email bodies and other multiline fields through CAT/TMS export.
Run YAML parser validation before linguistic closeout.
Render high-risk multiline fields in their final consumer.
Worked Example: A Folded Help Paragraph Becomes a Multiline UI Block
A help message is stored with > so maintainers can wrap source lines at a readable width while the application receives one prose paragraph. A localization export rewrites the scalar with | without changing the physical lines.
The target words remain correct, but the runtime string now contains a newline at every wrapped source line. The UI displays a narrow block of broken phrases and excessive vertical spacing.
Block Scalar QA parses source and target values and shows the difference directly: spaces in the source-equivalent value versus line feeds in the exported target. The serializer is configured to preserve folded semantics.
The translator does not retranslate anything. The defect was serialization style, not language.
Frequently Asked Questions
What is the difference between | and > in YAML?
| is literal block style and preserves line breaks. > is folded block style and folds ordinary line breaks to spaces while preserving blank and more-indented structures according to YAML rules.
What does |- mean?
Literal style with strip chomping: preserve internal literal line breaks but remove the final line break and trailing empty lines.
What does |+ mean?
Literal style with keep chomping: preserve the final line break and trailing empty lines.
Can translators rewrap folded YAML prose?
Usually yes when the field intentionally uses folded style for prose, as long as logical paragraphs and more-indented content remain correct. Always test the parsed value.
Can CI test YAML block scalars?
Yes. Parse the YAML and assert semantic string invariants, and optionally lint lexical style for fields where presentation form itself matters.
YAML 1.2.2 Guidance
YAML 1.2.2 defines two block scalar styles: literal |, where line breaks are preserved, and folded >, where ordinary line breaks are folded while blank and more-indented lines retain stronger separation. It also defines strip -, clip (default) and keep + chomping for final line breaks and trailing empty lines.
The localization lesson is to treat block-scalar presentation as executable text semantics. The right QA comparison is the parsed string the application receives, with lexical preservation added only where the project explicitly requires it.
Conclusion
YAML Block Scalar & Chomping QA protects multiline translation from invisible serialization changes.
A fast workflow locks YAML control tokens, parses the target value, tests literal versus folded semantics, verifies terminal-newline behavior and round-trips representative multiline fields before scale.
When the serializer owns line semantics, translators can focus on the message instead of manually policing pipes, greater-than signs and trailing newlines.
Continue the Translation Series
Read How People Translate Quickly | YAML Anchors and Aliases QA.