← Back to homepage
Guide — ServiceNow Localization

Your ServiceNow instance is multi-language. Is every screen actually translated?

Enabling a language pack turns translation on. It doesn't keep every label, message, and form that gets added afterward translated - that's an ongoing job, not a one-time setting.

Written by the SwissNow IT team

Why translation gaps accumulate

A translated instance on day one doesn't stay that way by default. Every one of these keeps happening quietly, after go-live, without anyone deciding to skip a translation.

01

New fields and labels ship untranslated by default

A new form field, choice list, or UI label is created in the base language - a translated value only exists if someone deliberately adds one.

02

Custom applications rarely inherit platform translations

Custom-built modules and workflows sit outside what ships pre-translated, so their strings need translation added explicitly - which is easy to skip under deadline pressure.

03

Notification and email templates get updated in one language

A wording fix to a notification is a natural edit to make in the language the editor is working in - the equivalent edit in the other configured languages doesn't happen in the same pass.

04

Workflow and Flow Designer messages are easy to forget

Approval messages, generated task descriptions, and other user-facing text built inside a flow's logic are functional text first - translation is often an afterthought, if it's considered at all.

Where the gaps actually hide

Not every gap is equally visible. Some show up immediately to any user switching languages; others only surface for the specific role or process that touches them.

The obviously visible ones

A field label or choice value that falls back to the base language stands out immediately to a non-base-language user - these tend to get reported and fixed quickly, precisely because they're so visible.

The ones nobody reports

A notification email, an approval message, a rarely-used form - these get far less traffic from the people who would notice and report the gap, so an untranslated string can sit there indefinitely. The gap isn't rare because it's minor; it's undiscovered because the people who'd catch it aren't looking at it often.

Where to look first

  • Anything added or changed after go-liveThe original rollout was translated as a project - everything since has depended on someone remembering.
  • Notification and email templatesLow visibility to whoever isn't the recipient, high visibility to whoever is.
  • Custom application screensOutside the platform's own pre-translated surface area by definition.
  • Workflow and Flow Designer generated textWritten as functional logic first, user-facing wording second.

The manual version doesn't scale

Checking this properly means switching the instance into each configured language and clicking through every screen, form, and notification a user in that language would actually see - repeated every time something changes. On an instance with more than a couple of languages and any ongoing configuration work, nobody does that continuously by hand.

neo.ai

Running this review continuously, automatically

Our own platform, neo.ai, checks UI elements, labels, and messages against each configured language and flags what's missing - so gaps get caught before an end user hits a screen that's still in the wrong language. It's one of seven categories it watches across a ServiceNow instance.