Line Endings Check
The line endings check flags localized strings where newline style changes between source and target.
Supported: JSON, YAML, XLIFF, Android XML, Apple .strings/.xcstrings, and Java .properties.
Examples
{
"email.body": "Line one
Line two",
"terms.text": "A
B
C"
}{
"email.body": "1行目
2行目",
"terms.text": "A
B
C"
}email.body: LF changed to CRLF terms.text: mixed line endings in target
Plain text email, generated files, snapshots, and byte-sensitive integrations may preserve newline style exactly.
What LocaleQA checks
LocaleQA classifies newline style inside string values, such as LF, CRLF, or mixed line endings, and compares source and target strings on the same JSON/YAML path or XLIFF unit.
This tends to happen after files move through different editors, operating systems, translation tools, or manual copy/paste steps. The JSON can still parse correctly while the string content has changed.
What appears in the report
The report shows the affected path and the source-target newline style difference. It does not normalize line endings because the original bytes may matter to the product.
Developers typically decide whether line endings are significant. Localization PMs and vendors can use the finding to catch accidental export or editor changes before handoff.
When to keep or skip this check
Some projects intentionally normalize all localized strings to one line-ending style. In that case, a finding may confirm expected cleanup rather than a defect.
Disable this rule for scans where newline normalization is a documented part of the workflow. Keep it enabled for plain text templates, multiline legal copy, generated resource files, and regression-sensitive strings.
How to use the finding
LocaleQA reports the affected path, resource, or translation unit, the source and target values involved, and the rule that triggered the finding. Developers, localization PMs, vendors, and QA reviewers can use that as a specific file-level item to fix, approve, or discuss before release.
Some findings are valid exceptions. A migration file, documented style choice, or locale-specific convention may explain the difference. In those cases, teams can leave the string as-is or disable the check for that scan.
LocaleQA is deterministic localization file QA across web, mobile, and Java formats. It does not judge wording or rewrite translations; it surfaces the file issue so the responsible owner can decide the right fix.