Adding a second language to a ServiceNow instance is easy. Adding a tenth without breaking is the hard part. The failure mode is always the same: every English change requires manual translation in nine other places, translators fall behind, end users complain about stale content, and the program quietly retreats to “English only with translated chrome.”
Separate platform strings from content strings
Platform strings are field labels, button text, status values. These ship with translations from ServiceNow and need no maintenance from you. Content strings are knowledge articles, catalog descriptions, notification bodies, virtual agent responses. These are your problem. Many teams confuse the two and over-spend on platform translations that already exist.
Treat the source language as a contract
Pick one language as authoritative. Every change happens there first. Every other language is a translation of that source. Without this discipline you get drift where the French version says one thing, the German version says another, and the English version is missing a paragraph.
Use the Localization Framework, not field translations
The legacy Field Translations plugin works one column at a time and is painful to maintain at scale. The Localization Framework (sys_localization_*) treats translation as a workflow with status, reviewer, and version tracking. Translators see a queue of changed source content and translate against it. Skipping the framework is a false economy that you will pay back in audit findings.
Machine translate the first pass, human review the second
For knowledge content, run new and changed source through a machine translation API as a draft, then route to a human reviewer for approval. This cuts cost by 70 percent or more and reduces lead time from weeks to days. Crucially, mark machine-translated articles with a “draft translation” badge until human review completes; users tolerate roughness when they know it is provisional.
Notifications need template-level translation, not body-level
Translating notification bodies as free text means every template change requires re-translation. Instead, structure notifications as a fixed template with variable substitution: “Incident ${number} assigned to ${assigned_to}.” Translate the template once, and variable values flow through unchanged. This collapses your notification translation workload by an order of magnitude.
Choice lists need explicit translation sets
Choice values render based on the user’s session language. Maintain a complete translation set for every active choice on user-facing fields. Run a query for sys_choice rows where active is true and confirm a translation exists for each language you support. Missing translations show the raw English value and look broken.
Knowledge articles need a parent-translation model
The KB application supports article translations as child records of a source article. Editors update the source, the system flags translations as “out of date,” translators work through the queue. Build a Performance Analytics indicator for “translations more than 30 days behind source” and review weekly. A culture of low translation lag is more valuable than perfect coverage of dead articles.
What to do this week: pick your authoritative source language, audit your active translation languages, and adopt the Localization Framework if you are still on field translations.
