A new starter abroad opens a laptop, follows the setup guide, and loses most of a day. Not because the guide is wrong, but because it was written for somebody who shares a language, a keyboard layout and a set of assumptions with the person who wrote it.
TL;DR
- Day-one setup is the highest-stakes IT content you have, because the person following it cannot ask for help yet.
- Only a small part of a setup guide needs translating. The screenshots and the exact strings matter more than the prose.
- Never translate menu labels, settings names or error text. Those are things the user must match character for character.
- Keyboard layout and regional OS defaults break more setups than language does, and nobody documents them.
- A pre-recorded walkthrough in the local language beats a translated document for the first ninety minutes.
- Put a named contact and a response time in the guide itself, not on an intranet page they cannot reach yet.
Why day one is different from every other ticket
Every other support interaction happens from a position of some capability. The person has access, knows where the help desk is, and has colleagues to ask. On day one they have none of that.
A new starter who gets stuck during setup cannot file a ticket, because filing a ticket requires the account they are trying to set up. They fall back to email, or to whoever recruited them, or to waiting. In a market where they are one of three people, waiting is often the only option available.
That makes setup content the one place where the cost of a small ambiguity is a lost day rather than a repeated question, and it is also the content most likely to have been written once and never revisited.
What actually goes wrong, and it is rarely the prose
Translated UI strings. The single most common failure. A guide saying to open a menu whose name has been translated into the local language, when the user’s machine displays the English label, is worse than no instruction. It is also the hardest for the writer to notice, because the translation looks correct.
Keyboard layout. Machines shipped with a layout that does not match the user’s expectation, or a password containing characters that are awkward to type on their keyboard. This generates a lockout, which generates a support request the user cannot make.
Regional OS defaults. Date formats, measurement units and language packs set at imaging time for one country. Harmless individually, and collectively they make the machine feel like somebody else’s.
Screenshots in the wrong language. Often more useful than the text, and almost never updated per market, so a user sees a picture that does not match their screen and stops trusting the whole document.
A worked example
A company hiring its first four people in a new market translated its onboarding guide properly, by a professional service, and still lost roughly a day per starter.
The cause was two lines. The guide told users to enter a Wi-Fi password containing a character that sits in a different place on the local keyboard layout, and it referred to a security prompt by a label that the translation had rendered into the local language while the machines displayed English. Three of the four starters locked themselves out, and none of them could file a ticket because the account was not yet active.
The fix was a glossary marking every UI string as untranslatable, a password policy avoiding layout-sensitive characters, and a named contact with a phone number printed in the guide. The next six starters completed setup in under an hour.
What to translate and what to leave alone
Checklist:
- Translate the explanatory prose, the order of steps and anything describing why a step exists.
- Leave every UI label, settings name, menu path and error string exactly as the machine displays it.
- Mark those strings in the source document so no translator or engine touches them.
- Check the keyboard layout the machine ships with against the market, and avoid layout-sensitive characters in temporary passwords.
- Note the regional OS defaults applied at imaging, and say how to change them.
- Print a named contact, a response time and a phone or messaging route in the document itself.
The marking step is what makes this durable. If the exact strings are tagged in the source, every future translation of that document inherits the protection without anybody having to remember.
Why a recording beats a document early on
For the first ninety minutes of a device’s life, a screen recording in the local language with a voiceover outperforms any written guide, for one reason: it shows the actual interface. A user watching a recording can see that the label on their screen matches the one in the video, which resolves the translated-string problem entirely.
It is also much cheaper to keep current than a translated document set. One recording per market, re-done when the imaging process changes, rather than a document with twelve embedded screenshots that each go stale independently.
Keep the written guide as the reference for everything after the first session, where searchability matters more than fidelity.
Where tooling helps and where it does not
An answer bot cannot help somebody who has no account yet, which is the honest limit on all of this. It helps enormously from day two onwards, when the same questions recur in volume. Figures below were read from each vendor’s own pricing page on 5 and 7 October 2026.
| Matram | $29, $69, $199 per month flat | 95+ languages | Answers from your own docs |
| SiteGPT | $468 and $948 billed yearly | 95+ languages | Answers from your own docs |
| Freshservice | $19, $49, $99 per agent plus $29 for Freddy AI | No count published | Can action provisioning requests |
| Zendesk | $55 plus $50 per agent per month | No count published | Can action provisioning requests |
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It has no free tier, it answers rather than actioning tickets, and it is not an ITSM platform, which is exactly the limit that matters for provisioning. If your day-one bottleneck is accounts not being created rather than instructions not being understood, a service management platform is the right purchase. The full set is in our multilingual IT support comparison.
Final thoughts
Setup instructions are the one piece of IT content read by somebody with no way to ask for help, which makes a small ambiguity expensive in a way it never is elsewhere. The failures are not linguistic. They are translated UI strings, keyboard layouts, regional defaults and screenshots that do not match the screen.
Mark the exact strings as untranslatable in the source, record a short walkthrough per market, and print a real contact with a real response time in the document. Those three things cost very little and remove most of the lost day.
Frequently asked questions
Which parts of a device setup guide should be translated?
Translate the explanatory prose, the order of the steps and anything describing why a step matters, and leave every literal interface string exactly as the machine displays it. That means menu labels, settings names, button text, menu paths and error messages stay in their original form, because the user has to match them character for character on their own screen. Marking those strings in the source document protects every future translation automatically.
Why do new starters abroad lock themselves out during setup?
Usually a keyboard layout mismatch rather than anything to do with language. A temporary password containing characters that sit in a different position on the local layout, or a machine shipped with a layout the user does not expect, produces repeated failed attempts and a lockout. The compounding problem is that a locked-out new starter cannot file a ticket, because filing one requires the account they are trying to activate, so check the shipped layout per market and avoid layout-sensitive characters in initial credentials.
Is a video better than a written guide?
For the first session yes, because a screen recording shows the actual interface and lets the user confirm that the label on their screen matches the one being demonstrated, which resolves the translated-string problem completely. It is also cheaper to maintain than a document containing a dozen screenshots that each go stale independently. Keep the written guide for everything after the first session, where being able to search for a specific step matters more.
Should screenshots be localised?
Either localise them properly per market or leave them all in one language and say so explicitly in the guide. The damaging middle ground is a translated document with screenshots in a different language from both the text and the user’s screen, because the mismatch makes the reader doubt the whole document rather than just the image. Screenshots are often the most useful element of a setup guide and the least likely to be updated, so whichever approach you pick, give them a review owner.
Can a support chatbot help with day-one setup?
Not usually for the first session, because somebody without an account generally cannot reach an internal tool, which is the honest limit on all self-service here. It becomes genuinely useful from day two onwards, when the same configuration and access questions recur across every new starter in a market and can be answered from your own documentation in whatever language the question arrives in. For day one itself, the effective tools are a recording, a printed contact and a phone number.
What should the escalation route in the guide look like?
A named person rather than a function, a response time expressed in the starter’s own working hours, and a channel that does not depend on the account being set up, which in practice means a phone number or a personal messaging route. Put it in the document itself rather than linking to an intranet page, since a user who is stuck during setup frequently cannot reach the intranet. Name a backup at the same time, because a single contact on annual leave leaves a new starter with nothing.
