Best Practice: Configuring Login Page Language for Unauthenticated Users in ServiceNow

[Palash_Sarkar]

Overview

A common ServiceNow internationalization issue is the login page displaying in the wrong language for users who haven't authenticated yet. This article covers a simple, reliable best practice for controlling that behavior — illustrated with a real 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.

---

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 rather than setting it to a specific language.

Why System, not an explicit language: - Out of the box, the guest user's preferred_language defaults to English — this is what causes the login page to display in English even in a Japanese environment. - Setting it to an explicit code like ja works for a single-language instance, but it hardcodes the guest experience and won't adapt if you later support multiple languages (e.g., via language cookie (com.glide.sys.glide_language_cookie_enabled) or region-based logic). - Leaving it blank makes the guest user fall 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.

---

Applying This to the Japanese Use Case

Step	Setting	Value
1	glide.sys.language	ja
2	guest preferred_language	(blank)
3	sys_user_preference (user.language, user=null)	Deleted

Result: Guest user has no explicit language → falls back to glide.sys.language (ja) → login page renders in Japanese for every unauthenticated visitor, on every release.

---

Why This Is the Best Practice

• Simple resolution path: guest preference (blank) → system default. No competing preference records to reason about.
• Release-independent: Works the same on every release, since it doesn't depend on cookie logic or system-wide preference precedence.
• Future-proof for multi-language: If you later need per-region languages, you're not fighting a hardcoded guest value — blank always defers correctly to whatever the system default is at the time.
• Easy to maintain: One property (glide.sys.language) 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

• ❌ Leaving guest preferred_language as "English" — this is the OOTB default and the direct cause of the English login page.
• ❌ Setting guest preferred_language to an explicit code (e.g., ja) instead of blank — works short-term, but hardcodes the guest experience and complicates future multi-language support.
• ❌ Leaving old sys_user_preference "user.language" records in place — these can silently override your intended configuration.
• ❌ Skipping the cache clear — old values may persist until cache is cleared.

---

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.

---

Summary

Action	Location	Setting
System default	System Properties	glide.sys.language = ja
Guest user	sys_user (guest)	preferred_language = blank
Cleanup	sys_user_preference	Delete user.language / user=null records

Key takeaway: For a predictable, upgrade-safe login page language, set your system default explicitly, leave the guest user's preferred language blank so it inherits that default, and remove conflicting system-wide preference records.