Hard-coded text can only be found by running the product

What it is

Hard-coded user-facing string detection finds interface text that bypasses message resources and therefore escapes translation and version tracking. Runtime or rendered-output scanning proves that an untransformed string reached a particular state, making it valuable for conditional branches, server errors, notifications, and third-party components. It is not the only discovery method. AST linting, static analysis, extraction diffs, and resource-usage tracing can locate many literals in source and templates earlier.

Why it happens

Hard-coded strings live across client components, templates, backend responses, user-facing error mappings, images, and platform manifests, so no detector observes the entire path. Static rules cover unexecuted code and pull-request diffs but struggle to decide whether a literal is user-facing; they miss runtime construction, reflection, remote configuration, and some compiled artifacts. Under a pseudo-locale, runtime scans make source-language remnants stand out after normal resources transform, but only in states that were reached and rendered. Resource graphs can expose missing, unused, and bypassed catalog paths when the build retains traceable relationships.

Studying it

Evaluate the detection stack with stratified seeded faults: direct UI literals, template copy, concatenation, server errors, push/email text, platform metadata, and third-party fallbacks. Measure precision, recall, localization time, and how early each detector reports. Describe runtime coverage by route, permission, feature flag, network outcome, and error state; code coverage is not equivalent to visible-string state coverage. Classify false positives such as brands, protocol terms, sample data, and reviewed non-translatables. An allowlist without rationale, owner, and expiry gradually becomes a blind spot.

Where it stops holding

Reading “can only be found by running” as a single-method claim is too strong. Runtime evidence is indispensable for dynamic and integrated paths, while static evidence reaches code before it is merged or executed; the two are complementary. A source-language remnant is not necessarily hard-coded—it may be a brand, user content, or an approved non-translatable term. Conversely, a literal can resemble pseudo-locale output or sit in an unreachable state. OCR can flag words baked into an image but cannot restore resource semantics. Passing detection proves traceability, not translation quality or layout fitness.

Applying it

• Run AST-based localization lint or platform static checks over source, templates, and manifests, targeting user-interface sinks and rejecting literals that bypass resource APIs. Give every exception a narrow category, rationale, owner, and review date instead of a global string allowlist.
• Diff extracted messages, catalog keys, reference graphs, and locale coverage during builds. Block new missing or unknown keys and calls that bypass the resource boundary; trace the source of server errors, notifications, emails, and platform metadata as well.
• Crawl critical routes, roles, feature flags, empty states, and failures under a pseudo-locale. Scan DOM or native view trees, accessible names, and screenshots for untransformed source strings, using reproducible fixtures to trigger rare errors rather than waiting for production.
• Merge static and runtime findings by file location, resource key, rendered state, and build version. Before release, require resolution or a narrowly reviewed exception for every hit, and continuously seed faults to measure detector misses instead of treating zero alerts as evidence of good translation.

Related

• Same group: S4.03.1 Pseudolocalization exposes layout failures before translations exist · S4.03.2 Cover the longest language and right-to-left languages
• Adjacent: S4.04.1 Copy changes must trigger the translation workflow · S1.07.4 Avoid embedding text in images
• Search terms: hard-coded string detection · localization lint · runtime string scan