Training and documentation driven by regional layouts must be prepared per region, not shared as one copy

What it is

Training decks, shortcut posters, onboarding videos, and troubleshooting pages drawn from one keyboard will point at the wrong keys in another region. Enter shape, punctuation placement, and dual-script legends all change; following the picture lands on empty space or the wrong character. Preparing materials per region is not a full-text translation. It means reshooting key art and rewriting “press this key” lines for the local shell and input source. Shipping one US-tenkey screenshot merely moves regional difference from the product into support cost.

Why it happens

Documentation is a second installed base. New hires drill from pictures, support staff remote-direct from pictures, and tutorial screenshots become canonical in search. Once art locks a particular Enter and number row, mismatch with the reader's machine is blamed on the user rather than on the picture. Translation changes language, not cap geometry: rendering “press the key above Enter” into German does not repair adjacency above an ISO inverted-L Enter. Localization pipelines therefore need a key-position review, not only copy translation.

Studying it

Sample the help center: which keyboard standard appears in figures, whether the layout is named, and what share of tickets come from mis-pointed keys. In usability tests, mismatch the document and the participant's machine (US art with an ISO board) and record completion and wrong-key presses. Content audit is more direct than lab typing—many products have never photographed a keyboard in the target market. Treating “the doc is translated” as “the doc is keyboard-localized” misses a whole defect class.

Where it stops holding

Pure touch products whose soft keyboards redraw with language need fewer physical key diagrams, though attached-board users remain. If a global product forces the same on-screen command panel rather than physical keys, one set of instructions can be shared. Internal tools that issue only one shell can keep a single doc version, provided the hardware policy is actually locked. Volunteer open-source docs patched region by region are uneven; do not assume coverage is complete.

Applying it

• Fork help-art templates for ANSI, ISO, and JIS, with layout codes in filenames; check Enter and the number row against a locally purchased board before release.
• Rewrite “press this key” lines to give both the character and the position (“type a backslash \, left of Enter on a US layout”) instead of relative position alone.
• Split onboarding by office region; do not teach every branch from headquarters keyboard footage.
• Verify by buying a retail keyboard in the target market and asking a support person who did not write the doc to enter the product's required special characters using only that doc; a wrong-key point fails the regional doc.

Related

• Same group: C6.18.1 ISO and ANSI boards differ in Enter and left-Shift geometry, a gap software cannot close · C6.18.2 Punctuation keys move with language layouts, so the same physical key emits different characters · C6.18.3 Non-Latin boards often print dual legends, with layout switching selecting the writing system
• Adjacent: C6.03 Shortcut systems · C6.17 Path dependence of keyboard layouts
• Search: keyboard localization · regional documentation · keycap screenshot