Best Practice: Configuring Login Page Language for Unauthenticated Users

[Palash_Sarkar]

Overview

A common ServiceNow Internationalization (i18n) question is how to control the language shown on the login page — the screen an unauthenticated user sees before signing in. The correct, supported way to do this is to set the System Default Language through the glide.sys.language property.

This behavior is by design: the guest user's language should NOT be changed. Setting the language on the guest account is a hack/workaround and should be avoided. Because the login page — and every user without a user role — inherits the system default, the glide.sys.language property is the single correct control point. Customers should be made aware that manipulating the guest account to force a login-page language is not a supported approach.

A note on the current product documentation. The System Localization → User-Specific Language topic currently states: "Setting the language for the system guest user sets the language for both the login page and all users without a user role." That statement is not correct. It is being corrected — i18n team is working with the technical writer to get it updated. Do not rely on the guest-user method; use glide.sys.language instead.

This article demonstrates the correct approach with a concrete use case: making the login screen display in Japanese.

Use Case Scenario

Goal: All unauthenticated users hitting the login page should see it in Japanese, regardless of browser settings.

Guest user's current preferred_language: English (the out-of-box default)

Target result: Login page renders in Japanese, consistently and predictably — without altering the guest account.

---

The Recommended Best Practice (3 Steps)

Step 1: Set the System Default Language Property

Property: glide.sys.language
Value: ja

Navigate to System Properties and set this value. This is the ultimate fallback used across all release versions — it should always be configured explicitly to your target language.

Step 2: Leave Guest User's Preferred Language System (日本語）

Table: sys_user
User: guest
Field: Preferred Language
Value: (blank)

Navigate to User Administration → Users → guest, open the record, and select the Language field System (日本語）which is blank appear in the list view.

Why the guest user must stay blank: - Changing the guest user's language is an unsupported hack. The by-design mechanism for the login-page language is glide.sys.language. - Out of the box, the guest user's preferred_language shows English; forcing another code here is exactly the workaround to avoid. - Left blank, the guest user falls back to glide.sys.language, so the login page always follows your system default — one setting to maintain, and it stays correct even if the system default changes later.

Step 3: Delete Conflicting sys_user_preference Records

Table: sys_user_preference
Condition: name = 'user.language' AND user IS NULL
Action: Delete all matching records

In the Navigator enter sys_user_preference.listOpen User Preferences table and filter on Name = user.language and User is empty, and delete any records found.

Why: This system-wide preference can override the guest user's setting on some releases, and is a frequent source of unpredictable login-language behavior after upgrades. Removing it leaves only two clear control points: the guest user record and the system property.

Result: No guest-account hack → the login page resolves to glide.sys.language (ja) → it renders in Japanese for every unauthenticated visitor, on every release.

---

Why This Is the Best Practice

• Supported and by design: glide.sys.language is the intended control for the login-page language. No workarounds on the guest account.
• Simple resolution path: system default → login page. No competing preference records or hacked accounts to reason about.
• Release-independent: Works the same on Yokohama, Australia, and later, without depending on cookie logic or preference precedence.
• Easy to maintain: One property is your single source of truth for the unauthenticated experience.

---

Verification Checklist

☑ glide.sys.language = ja
☑ guest.preferred_language = blank (not "English", not "ja")
☑ No sys_user_preference records where name='user.language' AND user is empty
☑ Cache cleared (Navigation filter → enter "cache.do")
☑ Login page tested in incognito window → displays Japanese

---

Common Mistakes to Avoid

• ❌ Changing the guest user's language to force a login-page language — this is an unsupported hack. Use glide.sys.language.
• ❌ Relying on the "set the guest user language" guidance — the current product doc statement on this is incorrect and being corrected.
• ❌ Leaving old sys_user_preference "user.language" records in place — these can silently override the intended configuration.
• ❌ Skipping the cache clear — old values may persist until cache is refreshed.

---

Troubleshooting: Login Page Still Not in Japanese

1. Check guest user record — confirm preferred_language is blank, not "English."
2. Check glide.sys.language — confirm value is ja.
3. Check for leftover preference records — filter sys_user_preference for name='user.language', user is empty; delete any found.
4. Clear cache and retest — go to the Navigation filter (top-left search bar), enter cache.do, and press Enter. Then retest in an incognito window.
5. Confirm the Japanese language pack is installed and active under System Definition → Languages.

---

Key takeaway: The login-page language is controlled by design through glide.sys.language. Set that property, leave the guest user alone, and remove conflicting system-wide preference records. Changing the guest account's language is a hack to be avoided — and the product documentation stating otherwise is being corrected.