UI Matching Check for Multilingual Manuals

The moment the manual and the product disagree, the user stops trusting the product. The manual says “press the POWER button.” The button is molded ON/OFF. The manual says the path is Settings > Wireless. The firmware says Settings > Network > Wireless. The user hunts for a menu that does not exist, then calls support.

None of that is a manual translation or technical document translation problem. The sentences can be flawless and the manual still fails, because the strings it quotes do not match the product. This guide covers the 15 checks that confirm a multilingual manual agrees with the shipping product: its UI, its physical buttons and labels, its on-screen messages, its part numbers, and its firmware version.

What is a UI matching check?
A UI matching check verifies, before release, that the product information quoted in a multilingual manual matches the product that actually ships. The subjects are the firmware version behind every screenshot, the molded text on buttons and ports, the exact strings of on-screen messages and menu paths, safety labels and certification marks, part numbers and barcodes, and document version data. Translation review judges sentences against the source. UI matching judges the document against the final firmware build and the physical product.

1. Why UI matching is its own QA area

A translator is responsible for what a sentence means. Whether the button name, menu path, on-screen message, molded text, label, or part number quoted in that sentence agrees with the shipping product is settled by holding the document against the firmware and the physical unit. No amount of language expertise detects the mismatch.

In a multilingual program, one UI change lands on dozens of language editions at once. A single screenshot, one menu name, one molded label out of step produces higher support call volume, an impression of incomplete localization, the wrong manual in the box, and, at worst, a failed safety-critical operation.

2. Without a fixed baseline date, the check means nothing

The most common failure in UI matching is not a missed item. It is comparing artifacts from different dates. If the manuscript is written against the March build, the screenshots were captured from the April build, and the molded-text drawing is the February revision, then all 15 checks can pass and the manual still will not match what ships.

Before you start, pin five artifacts to a single baseline date. This is the precondition for the entire check.

Reference artifact	What has to be locked	What it adjudicates
Final firmware build	Build number and build date	The source of every screenshot, menu path, and on-screen message
Per-language UI string resources	Firmware string files (.strings, .xml, .json)	The reference for character-level comparison of quoted text
Molded text and label drawings	Physical drawing or final artwork	The reference for button and port names, safety labels, certification marks
Part number and barcode list	Per-market box contents table	The reference for accessory lists and QR and barcode data
Manual manuscript	Document version and publication date	The artifact being checked against the four above

Operating principle. Do not leave the reference artifacts scattered across departments. Keep the final firmware version, the per-language UI strings, the label drawings, the part number list, and the manual manuscript inside the same release package. That is what holds the baseline date together.

3. The five areas product and document synchronization has to cover

Area	What has to be synchronized
Screenshots ↔ final UI	Shipping-build capture, per-language capture, how an English-only UI is disclosed, personal data scrubbed from screenshots
Molded text and physical labels	Button and port names, dual-marking convention where the molded text is fixed English, safety labels and certification marks
On-screen text ↔ quoted text	Character-level agreement of alerts, error codes, and menu paths, a shared firmware-manual glossary, and a consistent quoting convention
Part numbers and barcodes	Per-market box contents, part numbers, barcode and QR data verified with an actual scanner
Version and firmware sync	Document version, publication date, and a single tracked record of UI, molded text, and document changes

4. The five categories of the 15 checks

Category	What it covers	Checks
A. Screenshots ↔ final UI	Shipping build, per-language UI, English-UI disclosure, personal data in screenshots	4
B. Molded text and physical labels	Button, switch, and port names, dual-marking, safety labels, and certification marks	4
C. On-screen text ↔ quoted text	Alerts and menu paths, firmware strings, shared glossary, quoting convention	4
D. Part numbers and barcodes	Per-market box contents, part numbers, barcode and QR verification	2
E. Version and firmware sync	Change-control record for UI, molded text, and document changes	1

Severity distribution: Critical (A) 8 · Major (B) 6 · Minor (C) 1

5. Severity grades and the sign-off rule

Grade	Name	Definition and consequence if missed
A	Critical / mandatory	Leads directly to a failed user operation, inconsistent safety information, incorrect certification data, or a launch delay. Must be zero at sign-off.
B	Major / recommended	A miss produces customer claims, higher support call volume, rework, and erosion of brand trust. Target zero wherever possible.
C	Minor / supporting	Low impact individually. Accumulated, it drives quality variance between language editions and raises operating cost.

6. The 15 checks in detail

The table below expands each checklist line into working guidance. In production, record every item twice: once by the document owner (Self), once by an independent reviewer (Reviewer).

No	Check and acceptance criterion	Grade
1	A. Screenshots ↔ final UI Was every screenshot in the manual captured from the shipping firmware? Look for captures left over from interim development builds or earlier versions. Comparing screenshot capture dates against the shipping build date surfaces stale captures quickly.	A
2	A. Screenshots ↔ final UI Is the text inside each screenshot captured from that language’s UI build? Confirm that English UI screenshots have not been reused in non-English manuals. Capture from the per-language build.	A
3	A. Screenshots ↔ final UI If the product has no multilingual UI, does the manual state that the UI is displayed in English? Confirm the manual says so plainly, so readers do not assume they can change the display language. The wording and its placement stay consistent across every language edition.	B
4	A. Screenshots ↔ final UI Has personal and test data inside screenshots been scrubbed? Prevent exposure of real user names, email addresses, phone numbers, account IDs, and location data. Confirm dummy data was used.	B
5	B. Molded text and physical labels Do the button, switch, and port names in the manual match the molded text on the product exactly? Catch mismatches such as the manual saying POWER while the product is molded ON/OFF. Check icon markings the same way.	A
6	B. Molded text and physical labels Is the “product marking plus local-language gloss” convention applied consistently? Where molded text is fixed English or a symbol and a gloss is needed, confirm the convention, for example POWER (Encendido), is uniform throughout the document.	C
7	B. Molded text and physical labels Do the position, wording, and pictograms of warning and safety labels match the manual’s safety section? Confirm that pictograms and signal words under ANSI Z535.6, ISO 3864, and ISO 7010 are synchronized between the physical label and the manual.	A
8	B. Molded text and physical labels Do the certifications the product actually holds match the manual’s certification page? Confirm the mark types, certification numbers (including the FCC ID where applicable), and marking format agree. Reconcile against the approved mark list from Part 3 (Regulatory).	A
9	C. On-screen text ↔ quoted text Do alerts and menu paths match the firmware display character for character? Once the firmware strings are locked, compare every quoted string in the manual. Taking the firmware string resource files directly lets you verify down to words, symbols, and spaces.	A
10	C. On-screen text ↔ quoted text Are on-screen messages and the manual’s quotations written from the same translation basis? Confirm a single shared glossary governs both, so firmware translation and manual translation do not render the same message two different ways.	A
11	C. On-screen text ↔ quoted text Do menu path notations (for example, Settings > Network > Connect) match the per-language UI menu names? Confirm the per-language menu translation matches the manual, and that the path separator is used consistently.	A
12	C. On-screen text ↔ quoted text Is the quoting convention for buttons and menus (quotation marks, bold, brackets) consistent? Confirm the same convention is applied throughout the manual.	B
13	D. Part numbers and barcodes Do the part numbers in the accessory list match what is actually in the box? Confirm per-market differences in box contents are reflected, and that the manual describes the regional configuration accurately.	B
14	D. Part numbers and barcodes Do the part numbers, barcodes, and QR data agree between product and manual? Verify by scanning with an actual scanner and confirming the same data is returned. Visual comparison does not detect these errors.	B
15	E. Version and firmware sync Is there a change-control record covering UI, molded text, and manual changes? Confirm the product-to-document change history is traceable in a single system. Record the requester, the date applied, and the list of affected language editions.	B

7. Five errors found most often at incoming inspection

8. Error or correct: three worked examples

Screenshot version
✗ Error	Captures from the v2.3 development build are still sitting in the v2.5 release manual.
✓ Correct	Once firmware is locked, recapture from the shipping build, per language. A build change invalidates the existing captures.

Molded product text
✗ Error	The manual says POWER while the product is molded ON/OFF.
✓ Correct	Take the molded-text drawing as the single source and synchronize the manual to it. Where a gloss is needed, apply the dual-marking convention consistently.

Menu path
✗ Error	The manual says Settings > Wireless. The actual UI is Settings > Network > Wireless.
✓ Correct	Take the firmware string resources and compare the per-language menu paths against the manual’s quotations character for character, then update.

9. Running it as a two-stage cross-check

UI matching has to be revisited whenever firmware moves. Final sign-off, though, happens once, against a single baseline date fixed just before release. If the product and the document sit on different baseline dates, every check can pass and the manual can still miss the shipping build.

Stage	Who performs it	What they do	Sign-off criterion
Stage 1: author self-check	The technical writer or manual owner	Assemble the final firmware build, per-language UI captures, molded-text and label drawings, part number list, and change history on one baseline date, then walk the 15 checks.	Grade A at zero. Baseline date and build number recorded.
Stage 2: independent cross-check	A reviewer outside the manual work, plus firmware/UI and product label owners	Re-verify screenshots, menu paths, molded text, labels, part numbers, and the change record against the physical product or the final build.	Approve for release, or reject. A rejected file is corrected and re-verified.

10. How a manufacturer documentation team can adopt this

• Lock the firmware build number and the baseline date first. Every comparison that follows sits on that one date.
• Get the per-language UI string resource files directly from the firmware team. Transcribing from screenshots cannot guarantee character-level agreement.
• Obtain the molded-text drawing (physical drawing or final artwork) as a single source, and reconcile every button and port reference in the manual against it.
• Recapture screenshots from the shipping build, per language. Adopt a rule that a build change invalidates the entire existing capture set.
• Verify part numbers and barcodes with an actual scanner. Visual comparison does not work for this item.
• Record the firmware build number and the baseline date alongside the check results. When firmware updates later, that record tells you which items have to be rechecked.

Frequently asked questions