How People Translate Quickly | Localization Comment Leakage QA

If you search for localization comment leakage, translator notes in production, or XLIFF notes accidentally exported, the risk is not that comments are bad. Comments are useful working memory. They carry developer context, terminology decisions, reviewer questions, unresolved issues and source explanations. The failure happens when process metadata escapes its intended layer and becomes visible to users, shipped inside the wrong artifact, or exposed through an API or content export.

A fast translation QA workflow therefore treats comments, notes and annotations as governed metadata. The system should know which notes are source instructions, which belong to the translator, which are reviewer-only, which should survive round trips, and which must never reach the final target surface.

This guide explains how people translate quickly by detecting localization comment leakage before release. It covers XLIFF notes, CAT comments, developer notes, reviewer annotations, TODO markers, source comments, HTML comments, Markdown comments, metadata fields, JSON sidecars, screenshots, issue IDs, exported bilingual files, production bundles, APIs, CMS publishing and final rendered-page checks.

The owner job is distinct from Segment Comments. Segment Comments explains how to keep questions and answers attached to the exact sentence during work. Comment Leakage QA asks whether those internal notes remain properly scoped when the translation leaves the working environment.

1. Comments Are Process Metadata

Translator notes, developer instructions and reviewer annotations describe the work around a string rather than the user-facing string itself. They can be essential for understanding context and resolving ambiguity.

The release problem begins only when metadata crosses into a surface where the end user can see or retrieve it unexpectedly. QA should preserve useful process context while protecting output boundaries. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

A practical diagnostic is to identify the metadata channel, inspect export and publishing mappings, classify the note as permanent context, temporary query or public content, and then verify the final artifact contains only the fields and wording approved for that audience.

2. XLIFF Explicitly Supports Localization Notes

XLIFF provides note mechanisms for developer instructions, translator comments and other localization-process information. This makes notes a legitimate part of bilingual exchange rather than accidental clutter.

Because they are part of the interchange file, teams need explicit import/export policy. Structured notes should stay structured instead of being copied into target text. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

3. Notes Can Apply to Source or Target

Modern XLIFF supports notes and annotations associated with source, target, units or specific spans. That context is valuable during review.

A generic export pipeline that flattens annotations into plain text can accidentally expose them. Preserve annotation scope during conversion. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

4. CAT Comments Are Not Automatically Production Content

Most CAT tools maintain comments, statuses and reviewer notes separately from translated strings. The fact that a comment sits beside the target does not mean it belongs in the final file.

Export filters should map only the intended fields. Treat comments as metadata unless the destination specification explicitly says otherwise. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

5. Developer Notes Can Contain Sensitive Internal Context

A developer may explain unfinished features, internal code names, edge cases or roadmap details in a note. Those notes help translators choose the right wording.

They can also reveal information the public product is not meant to disclose. Production exports should not expose internal instructions accidentally. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

6. Translator Notes Can Contain Unresolved Questions

A translator may write ‘check with client’ or list several candidate meanings inside a comment. If that note leaks into target content, users can see internal uncertainty.

QA should search output artifacts for comment fields and common unresolved markers. Open questions belong in the workflow, not the user interface. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

7. Reviewer Notes Can Be Blunt by Design

Internal review often uses direct shorthand such as ‘wrong term,’ ‘awkward,’ or ‘source unclear.’ These notes are effective between professionals and inappropriate as published copy.

Do not sanitize them for users; keep them out of production entirely. Boundary control is safer than rewriting process commentary. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

8. TODO Markers Are High-Value Leakage Signals

Strings containing TODO, FIXME, TK, TBD, CHECK or similar markers deserve focused review. Some are legitimate user-facing acronyms, so context matters.

Custom regex QA can surface likely process residue. Treat the marker as a review candidate rather than deleting it blindly. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

9. Square-Bracket Notes Can Leak

Translators often use [CHECK], [CLIENT?], [TERM] or similar visible placeholders when comments are unavailable. Those markers can survive into export if they are stored in target text rather than metadata.

QA should scan the target for project-specific temporary markers. Visible drafting conventions need an explicit cleanup pass. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

10. Parenthetical Working Notes Are Harder to Detect

A translator may append ‘(confirm later)’ or ‘(source unclear)’ directly to a target during drafting. These resemble ordinary prose more than bracket tags.

Use comments instead of inline working notes whenever the tool supports them. Structural metadata is easier to QA than ad hoc prose annotations. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

11. HTML Comments Can Ship Invisibly

HTML comments may not appear on the rendered page but can remain in page source and be visible to users, crawlers or downstream processors. Internal localization notes should not be hidden in production HTML merely because browsers do not render them.

Inspect generated markup as well as screenshots. Invisible-to-render is not the same as private. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

12. Markdown Comments Depend on the Pipeline

Different Markdown processors support comments or hidden constructs differently. A note that disappears in one renderer may become literal text in another.

Do not rely on parser-specific hiding for internal translation notes. Keep process metadata outside publishable Markdown where possible. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

13. CMS Editorial Comments Can Publish Through Templates

Content management systems often provide internal notes, custom fields and revision comments. A poorly configured template or API can expose those fields.

Localization QA should know which CMS fields are editorial-only and which are publishable. Field mapping is part of release QA. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

14. JSON Metadata Can Leak Through APIs

A localization object may contain text, comment, description and internal status fields. An API response that serializes the whole object can expose internal metadata to clients.

Return only the fields the application contract requires. Backend schema design matters as much as translation export. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

15. Sidecar Files Need Release Filtering

Some localization workflows store comments in separate JSON, YAML or metadata sidecars. Those files are useful in repositories and unnecessary in public bundles.

Package rules should exclude internal-only sidecars from production. Artifact manifests can make this deterministic. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

16. Bilingual Files Should Not Be Shipped as Runtime Resources Unless Designed For It

XLIFF and similar bilingual formats can contain notes, alternative translations, metadata and reviewer information. Applications normally need compiled target resources rather than the full bilingual working file.

Shipping the bilingual artifact can expose far more than target text. Use the correct production format. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

17. Alternative Translations Are Not User Copy

Interchange formats and CAT projects can store alternatives from TM, MT or reviewers. A naive transformation can accidentally choose or expose more than one target.

Compile only the approved target state. QA should verify one intended user-facing value per resource. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

18. Comments Can Contain Personal Data

Reviewer names, email addresses, ticket links or user examples may appear in localization notes. If those notes leak, privacy exposure becomes possible.

Do not assume process metadata is harmless because it is ‘only comments.’ Apply the organization’s privacy and data-retention policy. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

19. Comments Can Contain Credentials or Secrets

Developers sometimes paste test tokens, internal URLs or environment details into notes despite policy. Production leakage can therefore become a security problem.

Secrets should not live in localization comments in the first place. Artifact scanning can provide a final protective layer. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

20. Issue Tracker Links Can Reveal Internal Systems

A note may reference a Jira, GitHub or internal incident URL. Publishing the URL can expose infrastructure names or access patterns even if the page itself is protected.

Keep issue references inside process metadata. Public copy should not depend on internal tracker context. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

21. Source Comments and Translator Comments Need Different Retention

Source-author notes may need to survive into future translation cycles, while temporary translator comments may be resolved and removed. Define lifecycle by comment type.

One blanket ‘delete all comments’ rule can destroy valuable context. Retention and production visibility are separate decisions. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

22. Resolved Comments Can Still Be Useful Historically

A resolved terminology discussion can explain why a project uses an unusual preferred term. Archiving the note in project history can prevent future debate.

It does not need to ship with the product. Keep historical knowledge in controlled repositories, not runtime resources. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

23. Unresolved Comments Should Block Release Where They Matter

An unresolved note tied to a critical target can indicate incomplete decision-making. Use status or query workflows to ensure required comments are resolved before delivery.

Do not infer that comment presence always blocks; some developer notes are permanent context. Classify note type and required action. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

24. Comment Count Can Be a Release Signal

A project can report unresolved translator questions separately from permanent developer context. Zero unresolved blocking comments is a useful release criterion.

Raw total comment count is not, because valid context notes may remain. Metrics need category and status. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

25. Round-Trip Export Can Change Comment Behavior

A CAT tool may import XLIFF notes as comments, preserve original notes on export, and omit tool-created comments—or use another policy. Do not assume note round-trip behavior.

Test a representative file with source notes, translator comments and reviewer annotations. Document what survives each boundary. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

26. memoQ and Similar Tools Distinguish Imported Notes

Current memoQ XLIFF 2 guidance says XLIFF notes can be imported as comments while original note elements remain in the XLIFF; comments created in memoQ do not necessarily export as new XLIFF notes. This demonstrates why tool-specific behavior matters.

Comment visibility inside the editor does not directly predict output. Test the actual export path. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

27. XLIFF Comments Can Annotate Spans

XLIFF 2.1 can associate comment annotations with particular spans of source or target content. Flattening those annotations into plain text would destroy the distinction between language and commentary.

Use XLIFF-aware processing. Do not process bilingual files with generic XML transformations that ignore annotation semantics. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

28. Screenshot Notes Can Leak Through Alt Text or Captions

Design-review workflows sometimes place translation notes directly on screenshots. If screenshots are reused in documentation, internal callouts can become public.

Use separate review layers or export clean versions. Visual assets need metadata boundaries too. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

29. Figma and Design Tool Comments Are Separate From Layer Text

Design tools provide comment systems, but teams sometimes put TODO notes inside text layers for convenience. Only text layers may be handed to localization or exported into product copy.

Use actual comments for process discussion. Do not encode workflow state inside user-facing layers. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

30. Spreadsheet Review Columns Can Be Mis-Mapped

A review spreadsheet may contain source, target, reviewer comment and status columns. Import scripts can accidentally treat the comment column as target text if headers shift or mappings are wrong.

Validate header mapping before bulk import. One column error can leak hundreds of internal notes. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

31. CSV Exports Need Header QA

When comments travel in CSV, confirm whether the destination expects them and under which header. A BOM or renamed header can shift automated mappings.

Use schema-aware import rather than column position alone. Structural QA and comment QA reinforce each other. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

32. Translation Memory Should Not Store Working Comments as Target

Copy-paste accidents can append a note to target text before confirming a segment. That polluted segment can then enter TM and reappear in future projects.

Search TM for known markers if leakage is discovered. Fix the asset, not only the current file. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

33. MT Training Data Should Exclude Process Notes

If bilingual corpora contain translator comments mixed into targets, models can learn to reproduce those artifacts. Clean metadata from linguistic training data.

Keep notes as separate fields when they have research value. Corpus hygiene affects future translation quality. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

34. LLM Prompts Can Echo Internal Notes

AI-assisted translation can receive developer context or reviewer comments in the prompt. If the model is not clearly instructed about what belongs in output, it may paraphrase or expose the note.

Separate instruction/context fields from output schema. Validate generated target for process markers. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

35. Prompt Context and Publishable Content Need Schema Separation

Structured AI workflows should distinguish source text, context note, glossary rule and target field. One large concatenated prompt encourages boundary confusion.

Output validation can require only the target field. Architecture reduces leakage risk before QA. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

36. Internal Terminology Notes Can Be Sensitive

A termbase entry may explain why a competitor name is avoided or reference confidential launch naming. Only the preferred target term should reach users.

Do not expose termbase notes through client-side bundles unless intentionally public. Glossary governance includes metadata visibility. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

37. Forbidden-Term Notes Should Not Publish

A termbase can contain ‘do not use X’ or legal rationale. Those instructions guide translators but are not user copy.

Ensure termbase exports used at runtime contain only approved fields. Translation resources can hold more than language. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

38. Comments in Source Code Can Be Extracted Accidentally

Localization extraction rules can capture developer comments if regex or XPath rules are too broad. The translation project then contains text that was never meant for users.

Preflight should sample extracted strings against source code context. Fix extraction rules rather than translating comments. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

39. Comments Can Be Intentionally User-Facing in Documentation

A sentence that says ‘Note:’ inside a manual is content, not process metadata. Do not suppress text merely because it contains words like note or comment.

Ownership depends on field and source structure. QA should target metadata channels and project-specific markers, not ordinary vocabulary. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

40. Developer Descriptions Can Become Useful Public Help Only by Explicit Decision

A context note may contain a clear explanation that editors later choose to publish. That is a content-authoring change, not an accidental export.

Move the wording into the source content through normal approval. Do not rely on leakage as a shortcut from note to publication. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

41. HTML Source Inspection Matters

A rendered page can look clean while internal comments remain in source. Crawlers, scrapers and technical users can still access them.

Run production HTML scans for internal markers or comment patterns when the risk matters. Screenshot-only QA is insufficient. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

42. API Contract Tests Can Exclude Internal Fields

Schema tests can assert that public endpoints return only approved localization properties. This is more reliable than asking reviewers to inspect every payload manually.

Internal notes can remain available on authenticated authoring APIs. Separation by contract is stronger than cleanup after serialization. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

43. Package Manifests Can Exclude Review Files

Production bundles should list intended localization assets explicitly. Review spreadsheets, annotated screenshots and bilingual interchange files can remain outside the package.

An allowlist is often safer than excluding known bad filenames. Artifact composition is part of localization QA. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

44. Search for Common Internal Markers

Custom QA can scan final text for TODO, FIXME, INTERNAL, QUERY, CLIENT?, DEV NOTE and project-specific tags. False positives are possible, especially in technical content.

Use context and case-sensitive patterns. A short project marker list can catch embarrassing residue cheaply. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

45. Search for Reviewer Initials Cautiously

Teams sometimes prefix comments with initials such as AB: or MK:. Those patterns can collide with legitimate content.

Use them only when the project has a consistent convention and the destination is prose. Specificity matters. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

46. Search for Ticket IDs Where Appropriate

Patterns like ABC-1234 can indicate issue references but may also be product codes. Combine prefix knowledge with project context.

Do not delete matches automatically. Flagging is safer than transformation. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

47. Filter Unresolved Comment Status Before Closeout

CAT and TMS systems often expose open/resolved states. Use those states to create a final issue queue.

Permanent developer notes can remain while blocking translator queries reach zero. Status-aware review is faster than reading every comment manually. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

48. Comment QA Complements Segment Comments

Segment Comments is the productivity owner for attaching context and questions to the exact sentence. Comment Leakage QA is the release owner for ensuring that metadata does not escape its intended channel.

Good workflows need both: rich working context and clean output. One enables collaboration; the other protects boundaries. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

49. Comment QA Complements Project Closeout

Closeout archives useful project knowledge and exports final deliverables. Leakage QA verifies that deliverables contain only intended public content before archive and release.

The two steps reinforce each other. A clean finish preserves internal context without shipping it. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

50. Comment QA Complements Build Validation

A resource file can parse and compile while still carrying exposed metadata fields or literal TODO text. Build success does not guarantee content-boundary correctness.

Run schema and rendered-output checks as needed. Technical validity and information governance are separate. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

51. CI Can Scan Artifacts for Forbidden Metadata

Automated release jobs can inspect JSON keys, HTML comments, known marker patterns or disallowed metadata fields. Keep rules narrow enough to avoid blocking legitimate content.

Artifact scanning is especially useful in repeated software releases. Automation makes the same boundary check every time. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

52. CMS Preview and Published Output Should Be Compared

A preview can include editorial overlays or unpublished fields that the public template excludes—or the reverse if mapping is wrong. Test the public route or API response, not only the editor.

Publishing is a transformation boundary. Comment leakage can occur there even when the translation record is clean. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

53. Mobile Bundles Need Offline Inspection

Internal metadata can remain inside app resource bundles even if the UI never displays it. If confidentiality matters, inspect packaged assets as well as rendered screens.

Users can often extract app resources. Non-rendered production data can still be exposed. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

54. Web Source Maps and Debug Bundles Can Expose Context

Localization metadata embedded in client-side JavaScript or source maps may become downloadable. Production build configuration should separate debug context from user bundles.

Do not store confidential localization notes in client code. Release engineering owns this boundary. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

55. Use the Principle of Least Publication

Only the fields required by the runtime or published document should leave the localization workflow. Everything else should remain in controlled authoring, review or archive systems.

This simplifies QA and reduces accidental disclosure. Minimal production artifacts are easier to reason about. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

56. Preserve Comments in the Right Archive

Removing notes from production does not mean destroying valuable context. Archive developer notes, resolved queries and terminology rationale with the project when policy permits.

Future translators can reuse the knowledge without exposing it to users. Retention and publication are different lifecycle decisions. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

57. Final QA Should Inspect Both Text and Metadata

Run a target-text marker scan and a structural metadata inspection. One catches inline residue; the other catches comment fields and notes that remain separate but publicly accessible.

Use the exact shipping artifact. Boundary checks belong at release. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

58. Make Every Leak a Pipeline Lesson

If a comment reaches production, identify which boundary failed: source extraction, CAT export, CMS mapping, API schema, build packaging or manual copy-paste. Fix that stage so the next release cannot repeat the same class of leak.

The long-term objective is not a bigger blacklist. It is a cleaner information architecture. The release question is not whether the note is useful internally; it is whether this specific artifact and audience are supposed to receive it.

Practical Localization Comment Leakage QA Workflow

List comment and metadata channels used by CAT tools, XLIFF, CMS, design tools and review spreadsheets.

Define which note types survive round trips and which must be resolved or removed before release.

Scan target text for project markers such as TODO, CHECK and unresolved query tags.

Inspect public APIs, HTML, app bundles and generated files for internal comment fields.

Use allowlists for production resource fields where practical.

Archive valuable notes separately from runtime or published artifacts.

Trace any leak to the pipeline boundary that exposed it and fix that stage.

Worked Example: A Reviewer Note That Reached the App

A review spreadsheet contains columns for key, source, target and reviewer_comment. During a rushed import, a header change shifts the mapping and several reviewer comments are loaded as target values.

The application still builds because every key has a string. One screen displays ‘Please check this term with Legal’ to users. Build validation cannot detect the problem because the resource is structurally valid.

Comment Leakage QA catches the marker ‘Please check’ and the import audit reveals that the comment column was mapped incorrectly. The team restores target values and changes the import to map by explicit field name rather than column position.

The lesson is that process metadata can become valid production data if field boundaries are weak. QA must protect meaning and metadata ownership, not just syntax.

Frequently Asked Questions

Should all XLIFF notes be removed?

No. Notes are legitimate localization metadata and may need to survive bilingual round trips. The requirement is that they do not become unintended user-facing content or publicly exposed metadata.

How is this different from Segment Comments?

Segment Comments explains how to attach context and queries during work. Comment Leakage QA verifies those internal notes stay in the correct metadata channel at release.

Can hidden HTML comments count as leakage?

Yes, if internal information remains publicly accessible in page source even though browsers do not render it.

What markers should final QA scan for?

Project-specific markers such as TODO, FIXME, CHECK, CLIENT?, INTERNAL, ticket prefixes and unresolved query tags can be useful. Keep the list narrow to avoid false positives.

Can this be automated?

Partly. CI can scan for known markers and forbidden metadata fields, but human context is still needed to distinguish genuine public notes from process residue.

XLIFF and Tooling Practice

The XLIFF specification explicitly defines notes as localization-process comments that can carry developer instructions, translator comments and other workflow information. XLIFF 2.1 also supports comment annotations tied to source or target spans. See the XLIFF 2.1 specification.

Current memoQ XLIFF 2 guidance documents that XLIFF <note> content can be imported as comments and that original note elements can remain in the XLIFF, while comments created in memoQ do not necessarily export as new XLIFF notes. That is exactly why comment behavior must be tested per tool and export path rather than assumed.

Conclusion

Localization comments are valuable because they preserve context, questions and review knowledge close to the text. They become a problem only when process metadata crosses the wrong boundary.

The fast workflow keeps notes structured, resolves blocking queries, scans target text for working markers, inspects production metadata fields and publishes only the content intended for the audience.

A mature localization system can keep rich internal context and still ship clean, minimal user-facing artifacts.

Continue the Translation Series

Read How People Translate Quickly | Segment Comments.

Read How People Translate Quickly | CAT Project Closeout.

Read How People Translate Quickly | Localization Build Validation.

How People Translate Quickly | Localization Comment Leakage QA: Keep Translator Notes, Developer Instructions and Review Comments Out of Production