Now Assist Multi-Language Knowledge Management: Diagnosis & Resolution PlaybookSummary :root { --ink: #16232b; --ink-light: #445a63; --ink-muted: #7d8f97; --surface: #f4f8f7; --card: #ffffff; --border: #dde6e5; --accent: #2563eb; --accent-soft: #eff4ff; --accent-dark: #1d4ed8; --green: #059669; --green-soft: #ecfdf5; --amber: #d97706; --amber-soft: #fffbeb; --red: #dc2626; --red-soft: #fef2f2; --purple: #7c3aed; --purple-soft: #f5f3ff; --teal: #0891b2; --teal-soft: #ecfeff; --brand-dark: #032d42; --brand-dark2: #0a4a63; --wasabi: #63df4e; --wasabi-dark: #2f8f3f; --wasabi-soft: #eafce6; --radius: 10px; --shadow-sm: 0 1px 3px rgba(3,45,66,0.08); --shadow-md: 0 4px 16px rgba(3,45,66,0.10); --shadow-lg: 0 8px 32px rgba(3,45,66,0.12); } *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: 'DM Sans', -apple-system, sans-serif; background: var(--surface); color: var(--ink); line-height: 1.65; -webkit-font-smoothing: antialiased; } /* ── HEADER ── */ .hero { background: linear-gradient(135deg, #032d42 0%, #0a4a63 55%, #0f5c73 100%); color: white; padding: 56px 32px 48px; position: relative; overflow: hidden; } .hero::before { content: ''; position: absolute; inset: 0; background: radial-gradient(ellipse at 70% 20%, rgba(99,223,78,0.18) 0%, transparent 60%), radial-gradient(ellipse at 20% 80%, rgba(15,92,115,0.25) 0%, transparent 50%); } .hero-inner { max-width: 960px; margin: 0 auto; position: relative; z-index: 1; } .hero-badge { display: inline-flex; align-items: center; gap: 6px; background: rgba(255,255,255,0.1); border: 1px solid rgba(255,255,255,0.15); padding: 5px 14px; border-radius: 20px; font-size: 12px; font-weight: 600; letter-spacing: 0.5px; text-transform: uppercase; margin-bottom: 20px; } .hero-badge .dot { width: 6px; height: 6px; border-radius: 50%; background: #34d399; } .hero h1 { font-size: 32px; font-weight: 700; line-height: 1.25; margin-bottom: 12px; } .hero p { font-size: 16px; color: rgba(255,255,255,0.75); max-width: 640px; line-height: 1.6; } .hero-meta { display: flex; flex-wrap: wrap; gap: 24px; margin-top: 24px; font-size: 13px; color: rgba(255,255,255,0.55); } .hero-meta span { display: flex; align-items: center; gap: 6px; } /* ── LAYOUT ── */ .container { max-width: 960px; margin: 0 auto; padding: 0 24px; } .content { padding: 40px 0 80px; } /* ── TOC ── */ .toc { background: var(--card); border: 1px solid var(--border); border-radius: var(--radius); padding: 28px 32px; margin-bottom: 40px; box-shadow: var(--shadow-sm); } .toc h2 { font-size: 14px; text-transform: uppercase; letter-spacing: 0.8px; color: var(--ink-muted); margin-bottom: 16px; } .toc-grid { display: grid; grid-template-columns: 1fr 1fr; gap: 8px 32px; } .toc a { display: flex; align-items: center; gap: 10px; text-decoration: none; color: var(--ink); font-size: 14px; font-weight: 500; padding: 6px 0; transition: color 0.2s; } .toc a:hover { color: var(--accent); } .toc-num { width: 24px; height: 24px; border-radius: 6px; font-size: 11px; font-weight: 700; display: flex; align-items: center; justify-content: center; flex-shrink: 0; background: var(--wasabi-soft); color: var(--wasabi-dark); } /* ── USE CASE CARDS ── */ .use-case { background: var(--card); border: 1px solid var(--border); border-radius: var(--radius); margin-bottom: 28px; box-shadow: var(--shadow-sm); overflow: hidden; transition: box-shadow 0.25s; } .use-case:hover { box-shadow: var(--shadow-md); } .uc-header { padding: 24px 32px 20px; display: flex; align-items: flex-start; gap: 16px; border-bottom: 1px solid var(--border); } .uc-icon { width: 44px; height: 44px; border-radius: 10px; flex-shrink: 0; display: flex; align-items: center; justify-content: center; font-size: 20px; } .uc-icon.blue { background: var(--accent-soft); } .uc-icon.green { background: var(--green-soft); } .uc-icon.amber { background: var(--amber-soft); } .uc-icon.purple { background: var(--purple-soft); } .uc-icon.red { background: var(--red-soft); } .uc-icon.teal { background: var(--teal-soft); } .uc-title { font-size: 18px; font-weight: 700; line-height: 1.35; } .uc-tags { display: flex; flex-wrap: wrap; gap: 6px; margin-top: 8px; } .tag { font-size: 11px; font-weight: 600; padding: 3px 10px; border-radius: 5px; text-transform: uppercase; letter-spacing: 0.3px; } .tag-zing { background: #dbeafe; color: #1d4ed8; } .tag-ais { background: #e0e7ff; color: #4338ca; } .tag-esc { background: #fce7f3; color: #be185d; } .tag-sp { background: #fef3c7; color: #92400e; } .tag-i18n { background: #d1fae5; color: #065f46; } .uc-body { padding: 24px 32px 28px; } /* Section blocks inside use cases */ .section-label { font-size: 11px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.8px; color: var(--ink-muted); margin-bottom: 8px; margin-top: 20px; } .section-label:first-child { margin-top: 0; } .uc-body p { font-size: 14.5px; color: var(--ink-light); margin-bottom: 10px; } .steps { list-style: none; margin: 8px 0 16px; padding: 0; } .steps li { display: flex; gap: 12px; font-size: 14px; color: var(--ink-light); padding: 7px 0; border-bottom: 1px solid #f1f3f8; } .steps li:last-child { border-bottom: none; } .step-num { /* a real span element carries the number now, no CSS counter/::before dependency */ width: 22px; height: 22px; border-radius: 6px; flex-shrink: 0; display: flex; align-items: center; justify-content: center; font-size: 11px; font-weight: 700; font-family: 'JetBrains Mono', monospace; background: var(--surface); color: var(--ink-muted); margin-top: 1px; } code, .code { font-family: 'JetBrains Mono', monospace; font-size: 13px; background: #f1f3f8; padding: 2px 7px; border-radius: 4px; color: var(--accent-dark); } /* Reference badges */ .refs { display: flex; flex-wrap: wrap; gap: 6px; margin-top: 16px; padding-top: 16px; border-top: 1px solid var(--border); } .ref { display: inline-flex; align-items: center; gap: 5px; font-size: 12px; font-weight: 500; padding: 4px 12px; border-radius: 6px; text-decoration: none; transition: all 0.2s; } .ref-kb { background: #eff6ff; color: #1e40af; border: 1px solid #bfdbfe; } .ref-kb:hover { background: #dbeafe; } .ref-doc { background: #faf5ff; color: #6b21a8; border: 1px solid #e9d5ff; } .ref-doc:hover { background: #f3e8ff; } .ref-comm { background: #ecfeff; color: #155e75; border: 1px solid #a5f3fc; } .ref-comm:hover { background: #cffafe; } .ref-icon { font-size: 13px; } /* ── CALLOUT ── */ .callout { border-radius: 8px; padding: 16px 20px; margin: 14px 0; font-size: 13.5px; line-height: 1.75; position: relative; padding-left: 48px; } .callout-warn { background: var(--amber-soft); border-left: 4px solid var(--amber); color: #78350f; } .callout-info { background: var(--accent-soft); border-left: 4px solid var(--accent); color: #1e3a8a; } .callout-tip { background: var(--wasabi-soft); border-left: 4px solid var(--wasabi-dark); color: #173d1d; } .callout-icon { position: absolute; left: 18px; top: 17px; font-size: 18px; line-height: 1; } .callout p { margin: 0 0 8px; } .callout p:last-child { margin-bottom: 0; } .callout code { background: rgba(0,0,0,0.07); padding: 1px 5px; border-radius: 3px; font-size: 12px; font-family: 'JetBrains Mono', monospace; color: inherit; font-weight: 500; word-break: break-all; } .callout strong { font-weight: 700; } .prop-list, .callout .prop-list { margin: 8px 0 0; padding: 0; list-style: none; } .prop-list li, .callout .prop-list li { padding: 4px 0; font-size: 13px; color: var(--ink-light); display: flex; align-items: baseline; gap: 8px; } .callout .prop-list li { color: inherit; } /* arrow bullet is now a real span in the markup, no ::before/content dependency */ /* ── PROPERTY TABLE ── */ .prop-table { width: 100%; border-collapse: collapse; margin: 20px 0; font-size: 13.5px; } .prop-table th { text-align: left; padding: 10px 16px; background: var(--brand-dark); color: white; font-weight: 600; font-size: 12px; text-transform: uppercase; letter-spacing: 0.5px; } .prop-table th:first-child { border-radius: 8px 0 0 0; } .prop-table th:last-child { border-radius: 0 8px 0 0; } .prop-table td { padding: 11px 16px; border-bottom: 1px solid var(--border); color: var(--ink-light); vertical-align: top; } .prop-table tr:nth-child(even) td { background: #fafbfd; } .prop-table tr:last-child td:first-child { border-radius: 0 0 0 8px; } .prop-table tr:last-child td:last-child { border-radius: 0 0 8px 0; } /* ── DECISION TREE ── */ .decision { background: var(--card); border: 1px solid var(--border); border-radius: var(--radius); padding: 28px 32px; margin-bottom: 28px; box-shadow: var(--shadow-sm); } .decision h2 { font-size: 20px; font-weight: 700; margin-bottom: 16px; } .decision-flow { display: flex; flex-direction: column; gap: 0; } .decision-node { display: flex; align-items: stretch; gap: 16px; } .decision-line { width: 32px; display: flex; flex-direction: column; align-items: center; flex-shrink: 0; } .decision-dot { width: 12px; height: 12px; border-radius: 50%; border: 3px solid var(--wasabi); background: white; flex-shrink: 0; } .decision-stem { width: 2px; flex: 1; background: var(--border); } .decision-content { flex: 1; padding: 0 0 24px; } .decision-q { font-size: 14px; font-weight: 600; color: var(--ink); margin-bottom: 4px; } .decision-a { font-size: 13px; color: var(--ink-light); } .decision-a em { color: var(--accent); font-style: normal; font-weight: 600; } /* ── FOOTER ── */ .footer { background: var(--brand-dark); color: rgba(255,255,255,0.55); padding: 32px; font-size: 13px; text-align: center; } @media (max-width: 640px) { .hero { padding: 36px 20px 32px; } .hero h1 { font-size: 24px; } .toc-grid { grid-template-columns: 1fr; } .uc-header, .uc-body { padding-left: 20px; padding-right: 20px; } .prop-table { font-size: 12px; } .prop-table th, .prop-table td { padding: 8px 10px; } } Knowledge Base Playbook A comprehensive troubleshooting playbook covering multi-language search failures, AI Search language filtering, Now Assist for Virtual Agent multilingual retrieval, translation configuration, and portal-specific behaviors. 📂 Category: Knowledge Management — Language & Translations ⚡ Applies to: AI Search · Zing · Now Assist VA · Service Portal · ESC · /kb Portal 🧭 Decision Tree — Which Fix Do I Need? Grouped by engine and layer so you can jump straight to your symptom — each branch routes to the exact use case with the fix. 🧭 Start Here — Identify Your Engine This single question resolves most multi-language tickets before you touch a property. Does your portal use AI Search or Zing? Check the portal record → Enable AI Search flag. ESC and Now Assist typically use AI Search. The /kb portal and classic Service Portal widgets typically use Zing. 💡 Zing properties (glide.knowman.*) and AI Search properties (glide.ais.*) are completely independent — setting one has no effect on the other. This mismatch is the single most common source of confusion in multilingual KB setups. 🔵 Zing Search Fixes Portal is /kb or a classic Service Portal / Employee Center widget. Do you want ALL languages in results, or only the user's own language? All languages → set glide.knowman.enable_multi_language_search = true→ Use Case 1Only the user's language → set it to false→ Use Case 3 🟣 AI Search — Retrieval & Language Filtering Portal is ESC, or the issue is topic/taxonomy pages or country-based language rules. Do you need cross-language results in AI Search? Global fallback (simple) → enable_global_language_fallback = true→ Use Case 2Per-country control → configure ais_country_to_search_language→ Use Case 7Full Zing-like behavior → apply the Dev Community workaround → Use Case 2, Option B Is a specific taxonomy/topic page returning zero results in one language? Check for a case-mismatched or missing topic_path translation in sys_translated_text, then re-index→ Use Case 11 Is a country-to-language mapping configured, but the wrong language set still appears? Verify sys_user.country is populated and rule out relevance before blaming the mapping→ Use Case 16 🤖 Now Assist Virtual Agent Issue reproduces specifically through Virtual Agent / Now Assist conversational search. Is Now Assist VA not finding KB articles at all in a non-English language? Update glide.ais.global_searchable_filter.kb_knowledge to include the target KBs→ Use Case 8 Is Now Assist returning English, or an unrelated third language, for a non-English query? Check the Now Assist in AI Search plugin version and translator configuration before assuming a translation gap→ Use Case 9 Does the VA's first non-English message fail, but later messages work? Confirm Language Detection and Dynamic Translation are both enabled — they are independent toggles→ Use Case 14 Is the VA's answer in the wrong language, or switching register (Du/Sie) mid-answer? Check skipDefaultLanguageInstruction on the Synthesised Answer and Router components→ Use Case 15 Does Live Agent transfer intermittently fail in a non-English language? Confirm the transfer phrase is mapped for that language; if configuration is already correct, this may be a defect to escalate→ Use Case 17 🪄 Portal Widgets & Labels The data and properties are correct, but something on the page still renders in the wrong language. Are KB categories blank in non-English? Known defect fixed in Xanadu Patch 2 → upgrade, or import the widget XML fix→ Use Case 6 Are facet or filter labels staying in English? Confirm you're on the current OOB facet widget and translations exist in both sys_ui_message and sys_translated_text→ Use Case 12 Is a stock (OOB) field or label not translating, even though the translation exists? Check for a missing i18 field prefix against an OOTB instance→ Use Case 13 🌐 Translation Data & Pipeline The problem is upstream of search — in how translations are created or stored. Are translations not being created at all? Check the I18N v2 plugin, language-specific translation plugins, the KB's Languages related list, and the translation task property→ Use Case 5 Are duplicate or inconsistent translation records causing search to resolve to the wrong record? Look for more than one sys_translated_text row resolving to the same sys_id, then de-duplicate and re-index→ Use Case 10 ⚠️ Access & Platform Errors Not a language-filtering issue — a scope or permissions error. Getting "scope access denied" errors for AI Search? Create a cross-scope privilege record: Source Scope = Advanced AI Search Management Tools → Target Table = sys_language → Operation = Read → Status = Allowed. 🗺️ Failure Domain Map — Which Engine Governs Which Surface Start here: most multi-language tickets trace back to fixing the wrong engine's properties. Portal / ExperienceSearch EngineGoverning Property NamespaceTypical Symptom/kb PortalZing Searchglide.knowman.*No cross-language results by default (Use Case 1); both language versions shown if left too permissive (Use Case 3)Employee Center / Service Portal — KB Categories widgetZing Searchglide.knowman.* + sys_translated_textKB Categories - KBv3 widget renders blank in non-English (Use Case 6)ESC PortalAI Searchglide.ais.translate.* + ais_country_to_search_languageDifferent result count vs /kb portal for the same query; glide.knowman.* properties have no effect (Use Cases 2, 4, 7)Now Assist for Virtual AgentAI Search + LLMglide.ais.global_searchable_filter.kb_knowledgeNo article found when the user's query language differs from the article's language (Use Case 8)AI Search Topic / Taxonomy PagesAI Searchsys_translated_text (topic_path)Topic Search widget returns zero results in non-English (Use Case 11)Portal Facets & FiltersAI Searchsys_ui_message + sys_translated_textFacet/filter labels stay in English or render mixed-language (Use Case 12)OOB Portal Fields & LabelsPlatformi18 field prefix + sys_ui_messageStock fields fail to translate despite a translation existing (Use Case 13)Now Assist VA — Language DetectionAI Search + LLMNow Assist Admin: Language Detection / Dynamic Translation togglesFirst non-English message returns English or a generic fallback (Use Case 14)Now Assist VA — Answer SynthesisAI Search + LLMskipDefaultLanguageInstruction / contextLanguageAnswer language or register (Du/Sie) is inconsistent (Use Case 15)Now Assist VA — Live Agent HandoffAI Search + LLMTransfer-intent detection (language-dependent)Live Agent transfer intermittently fails in non-English (Use Case 17) 🔀 Language Resolution Flow — Zing vs. AI Search Side by Side The two engines resolve language independently. A property set on one side has no effect on the other. Zing Path — /kb Portal User searches the /kb portal ↓ Zing checks:glide.knowman.enable_multi_language_search ↓ true — all-language articles returnedUse Case 1 false (default) — session-language onlyUse Case 3 AI Search Path — ESC / Now Assist VA User searches ESC or asks Now Assist VA ↓ AI Search applies its own internal language filter — independent of glide.knowman.*Use Cases 2, 4 ↓ Optional broadening:enable_global_language_fallback · ais_country_to_search_language · global_searchable_filter.kb_knowledge ↓ Cross-language or globally searchable results returnedUse Cases 2, 7, 8 Use Cases in This Playbook ?Decision Tree — Which Fix Do I Need?🗺Failure Domain Map🔀Language Resolution Flow 1Multi-Language Search Returns No Results 2AI Search Ignores Multi-Language Property 3Both Translated & Original Articles Show 4ESC vs KB Portal — Different Results 5Translation Plugins Not Working 6KB Categories Blank in Non-English 7AI Search Country-to-Language Configuration 8Now Assist VA — KB Not Found in Other Languages 9Now Assist / AI Search Returns English or Wrong-Language Articles10Duplicate Translation Records Break Language Resolution11Topic / Taxonomy Search Returns Zero Results12Facet / Filter Labels Not Translated13Out-of-the-Box Portal Labels Not Translating14Language Detection Fails on First / Switched Turn15Dynamic Translation Not Applied to the Synthesized Answer16Country-to-Language Mapping Configured but Not Taking Effect17Live Agent Transfer Fails Intermittently in Non-English⚙Key System Properties Reference 🔍 Use Case 1: Multi-Language Search Returns No Results Across Languages Zing Search Service Portal Problem An English-speaking user searches for a keyword present only in a French Knowledge article. No results appear. When a French-speaking user searches for the same keyword, the article appears correctly. By default, the Knowledge search engine restricts results to the user's session language. Steps to Reproduce 1Navigate to the Service Portal or Employee Center.2Set user language to English via Profile settings.3Search for a keyword that exists in a French-language KB article (e.g., "MABUCIG").4Observe: no results returned for that article.5Switch user language to French and repeat the same search.6Observe: the French article now appears in results. Root Cause The system property glide.knowman.enable_multi_language_search is not enabled. When set to false (default), the knowledge search engine only returns articles matching the user's session language. Resolution 1Navigate to sys_properties.list → locate glide.knowman.enable_multi_language_search → set value to true.2Verify glide.knowman.search.default_language is set to your primary language (e.g., en).3Clear instance cache: navigate to cache.do.4Reindex Knowledge articles: Knowledge → Administration → Text Indexes → select kb_knowledge → Re-index.5Test with users in different language sessions to confirm cross-language results now appear. ℹ️ This property works with Zing search only, not AI Search. If your portal uses AI Search (e.g., ESC), see Use Case 2. 📘 KB0965801 📘 KB0862447 📘 KB2080419 📄 KM Properties Doc 🤖 Use Case 2: AI Search Ignores the Multi-Language Search Property AI Search ESC Portal Problem Even after enabling glide.knowman.enable_multi_language_search = true, confirming the AI Search indexed source has no language filter, verifying article language fields, and even deactivating the "knowledge query" Business Rule — AI Search continues to implicitly filter results by the user's session language. Root Cause The glide.knowman.enable_multi_language_search property is designed for Zing search only, not AI Search. AI Search has its own internal language filtering mechanism. ServiceNow Product Management has confirmed this as "Working as Expected". ⚠️ Key insight: The multi-language search property works on the /kb portal (Zing) but does NOT affect the ESC portal (AI Search). This is the single most common source of confusion in multilingual KB setups. Resolution — Option A: Enable Global Fallback Language 1Set glide.ais.translate.enable_global_language_fallback = true.2Optionally set glide.ais.translate.global_fallback_locale = en-US (or desired fallback). If not set, it defaults to glide.system.locale.3This will return articles in both the user's session language AND the fallback language. Resolution — Option B: Community Workaround 1Apply the workaround from the ServiceNow Developer Community Share: developer.servicenow.com — AI Search Knowledge Language Internationalization 2This makes AI Search find KB articles as if it adheres to Multi-Language Search and Default Search Language properties, like Zing does.3Test in sub-production first. This is a community workaround, not an OOB feature. ⚠️ Workaround limitations: Catalog Items search is unaffected (searches user locale with English fallback). Auto-Complete, Stop Words, and Synonyms behave the same. Typo Handling uses a union of user language and English dictionaries. Important: The workaround does NOT translate search terms — it only broadens which language articles are returned. Resolution — Option C: Country-to-Language Mapping See Use Case 7 for configuring the ais_country_to_search_language table to control which languages each user sees based on their country code. Resolution — Option D: Log an Enhancement Request 1Navigate to the ServiceNow Community Idea Portal.2Submit an Idea requesting native AI Search multi-language support. See KB0755878 for instructions. 🌐 Dev Community Workaround 🌐 Community Article — Multilingual AIS 📄 Global Fallback Language Doc 📘 KB0755878 — Idea Management 📘 KB0952508 — AIS Troubleshooting 📄 Use Case 3: Both Translated and Original Article Versions Display Simultaneously Zing Search I18N Problem After creating a German translation of an English KB article, both versions (English original + German translation) appear in the Knowledge Base listing regardless of the user's language. Expected behavior: only the version matching the user's session language should display. Steps to Reproduce 1Open a Knowledge Base (e.g., "KB IT Infrastructure — Competence Center").2Navigate to a category (e.g., "Processes & Guidelines").3Observe: both English and German versions of the same article are listed, regardless of user language. Root Cause The property glide.knowman.enable_multi_language_search is set to true, which by design shows articles in all languages simultaneously. Resolution 1Set glide.knowman.enable_multi_language_search = false.2Ensure translated articles are properly linked via the Translated Versions related list on the source article.3Verify the Language field on each article version is set correctly (English for original, Deutsch for German version, etc.).4Clear cache (cache.do) and test: English users see English articles, German users see German articles. 💡 Tip: Translated articles keep the same KB number but have different sys_ids. They must be linked via the Translated Versions related list to work correctly with language filtering. 📘 KB0965801 📘 KB0831958 🔀 Use Case 4: ESC Portal and /kb Portal Return Different Search Results AI Search Zing Search ESC Portal Problem A German-speaking user searches for "Lorum" in the ESC portal — only 1 result (German article). The same search in the /kb portal returns 2 results (German + English). The glide.knowman.enable_multi_language_search property is set to true. Root Cause The ESC portal uses AI Search, while the /kb portal uses Zing search. The multi-language search property only applies to Zing. AI Search applies its own implicit language filtering. Additionally, the glide.knowman.enable_multi_language_search property is specific to the knowman app and is not globally respected across all portals. Resolution 1Identify which search engine each portal uses: check the portal's Enable AI Search flag and the Search Application/Profile configuration.2For ESC (AI Search): enable glide.ais.translate.enable_global_language_fallback = true and set glide.ais.translate.global_fallback_locale = en-US.3If global_fallback_locale is not set, it defaults to glide.system.locale — verify what this is set to (e.g., if de.DE, German users will only see German articles since both session and fallback are German).4Check for pending ESC plugin updates that may affect search behavior — apply in sub-prod first.5Verify role-based and criteria-based ACLs are not restricting article visibility. Custom ACLs have been observed causing language-like filtering issues. ℹ️ Common gotcha: If your system locale is set to German and global language fallback is enabled, but no explicit fallback locale is configured, German users will only get German results — because the fallback defaults to the system locale, which is also German. Affected properties: →glide.system.locale = de.DE→enable_global_language_fallback = true→global_fallback_locale = NOT set (defaults to system locale) Fix: Set glide.ais.translate.global_fallback_locale to en-US explicitly so the fallback points to English. 📄 Enable Global Fallback Doc 📄 Fallback Locale Config Doc 🌐 Use Case 5: Translation Plugins Not Working / Articles Not Translatable I18N Service Portal Problem After installing the I18N: Knowledge Management Internationalization V2 plugin and configuring system properties, translation tasks are not created, translated articles don't appear, or translation requests are skipped. Resolution — Manual Translation Setup 1Confirm the plugin com.glideapp.knowledge.i18n2 is installed and active: System Definition → Plugins.2Install language-specific translation plugins for each target language (e.g., I18N: Spanish Translations, I18N: French Translations) via Plugins.3Open the affected Knowledge Base record (kb_knowledge_base table) → add supported languages in the Languages related list.4Set glide.knowman.translation.enable_translation_task = true.5Publish a source article → verify translation tasks are created in the Translated Versions related list.6Reindex: Knowledge → Administration → Text Indexes → kb_knowledge → Re-index. Resolution — Automatic Translation (Dynamic Translation) 1Activate the Dynamic Translation plugin (com.glide.dynamic_translation) via System Definition → Plugins.2Navigate to Dynamic Translation → Translator Configurations → configure a provider (e.g., Microsoft Azure Translator). Provide API keys, region, and set as Default.3Enable properties: glide.knowman.translation.enable_lf_article_translation = true and glide.knowman.translation.enable_localization_framework = true.4After publishing, translated content is auto-generated via the configured provider.5Reindex the Knowledge base after translations complete. 💡 Same KB number, different sys_ids: Translated articles retain the same KB article number but have unique sys_ids. They are linked via the Translated Versions related list on the source article. 📘 KB0610453 — Translation Troubleshooting 📘 KB1638770 — Translation Config Required 📄 Dynamic Translation Doc 📄 Localization Framework for KB 📄 Bulk Translation Doc 🏷️ Use Case 6: KB Categories Blank / Not Loading in Non-English Languages Service Portal Problem The KB Categories - KBv3 widget does not display category labels when the user switches their language from English to German, French, or any other non-English language. Categories appear blank or fail to load entirely, even when glide.knowman.enable_multi_language_search is set to true. Root Cause This is a known platform defect that has been resolved. The widget fails to render translated category labels when no translation exists for the user's selected language. Additionally, categories only appear if there are existing published articles in the user's session language within that KB. Resolution — Option A: Upgrade 1Upgrade the instance to Xanadu Patch 2 or later, which contains the fix for this known defect. Resolution — Option B: Widget XML Workaround 1Navigate to /sp_widget_list.do.2Right-click any column title → select Import XML.3Import the patched widget XML file provided by ServiceNow Support for the KB Categories - KBv3 widget fix. Resolution — Option C: Ensure Category Translations 1Verify category labels are translated in sys_translated or sys_translated_text tables for each target language.2Ensure there are published articles in the user's session language within that Knowledge Base. 📘 KB1337122 📘 KB1701107 — Known Error Article 📘 KB2687022 — Category Translation 🗺️ Use Case 7: AI Search Country-to-Language Configuration AI Search ESC Portal Problem Users in a specific country (e.g., Germany) need to see Knowledge articles in both their local language (German) and English, but AI Search only returns articles in the user's session language. The global fallback approach is too broad for organizations with diverse geographic requirements. Resolution 1Populate the Country Code field on each user's sys_user record (this is a choice list in the instance UI).2Navigate to ais_country_to_search_language table and create entries mapping countries to search languages. For example:Country=Germany, Search Language=EnglishCountry=Germany, Search Language=GermanCountry=United Kingdom, Search Language=EnglishCountry=United Kingdom, Search Language=German3After populating, AI Search will return articles in all mapped languages for users with matching country codes.4Reindex AI Search after configuration changes. 💡 This approach gives you granular per-country control over which languages appear in search results — more precise than the global fallback property. 📄 AIS Country to Search Language Form 📄 Assign KB Search Languages by Country 📄 Internationalization Support for AIS 🤖 Use Case 8: Now Assist for Virtual Agent — KB Articles Not Found in Non-English Languages AI Search Now Assist VA Multilingual Problem Now Assist for Virtual Agent is configured with LLM-based responses. KB articles exist in English. When an English-speaking user asks a question (e.g., "Slow laptop"), the VA finds the article and returns a summarized answer. When a non-English user (e.g., Spanish) asks the same question in their language (e.g., "computadora portatil lenta"), the VA returns no results and no summary — even though both users have access to the same articles. When the non-English user switches their profile language to English and asks in English, the article is found. The user's utterance is not automatically translated to English before the semantic search runs. Steps to Reproduce 1Set user language preference to a non-English language (e.g., Spanish, German, French).2Open the Virtual Agent or ESC portal search.3Enter a query in the user's native language (e.g., "Helfen Sie mir, mein Passwort zurückzusetzen" for German, or "computadora portatil lenta" for Spanish).4Observe: VA returns the default fallback message with no KB article match.5Switch user language to English, ask the equivalent question in English.6Observe: VA finds the article and provides an LLM-summarized response. Root Cause When a user's language preference is non-English, AI Search sends the retrieval request with the user's locale (e.g., locale='es' or locale='de'). This means it only looks for KB articles tagged in that language. Since the articles only exist in English, the search returns nothing. The utterance is NOT automatically translated to English before the semantic search runs — the search is locale-filtered, not content-translated. Why Common Properties Don't Fix This Customers frequently try these properties first, but they do not solve this particular retrieval issue: →sn_generative_ai.append_lang_in_prompt — Controls whether language is appended to the LLM prompt for response generation. Affects how the LLM answers, not how AI Search retrieves articles.→glide.ais.translate.enable_global_language_fallback — A fallback translation setting, not a retrieval filter override for VA.→glide.knowman.enable_multi_language_search — Designed for Zing search only; does not reliably fix AI Search retrieval used by Now Assist for VA. Resolution 1Navigate to System Properties (sys_properties_list.do) and search for glide.ais.global_searchable_filter.kb_knowledge.2If it exists, update its value. If not, create a new string property with that name.3Set the value to include the relevant KBs. For broad coverage use: active=true^workflow_state=published. For specific KBs, use an encoded query targeting those KB sys_ids.4Save the property.5Test: set user language to Spanish, open VA, enter "computadora portatil lenta." The English KB article should now be found and the VA summary should be returned in Spanish. ⚠️ Important caveat: Enabling this property makes the specified KBs globally searchable across all languages. Any user in any language will potentially see these articles in all search contexts, not just VA. If you have language-specific KBs you want to keep isolated, be selective about which KBs you include rather than using a blanket filter. 📄 Configure Global Search for KB Articles 🌐 Community — Enabling Multilingual Search with AIS 🌐 Multilingual Support for Now Assist Products 📄 Translation for Now Assist 🌏 Use Case 9: Now Assist / AI Search Returns English or Wrong-Language Articles AI Search Now Assist VA Problem A query in French, German, Chinese, or Italian returns an English-language answer or article — or an article in a completely unrelated third language — even though a same-language version exists or should have been retrieved. In some traces, Now Assist fetches a French KB while the user's session language is English; in others, a Chinese query returns Japanese-language articles instead of Chinese ones. Root Cause Several distinct causes have been confirmed behind this symptom: 1Now Assist / Virtual Agent returning English for a non-English request via the Synthesized Result Handler — addressed by updating the Now Assist in AI Search plugin (fixed line v12+; some instances required a version higher than v12). PRB19096222A translator-configuration / KB-language mismatch causing NAVA to fetch a KB in the wrong language — corrected by setting the translator configuration property com.snc.gen_ai.translator_configuration.sys_id and fixing catalog-item names. PRB19360773A cross-language retrieval defect returning KBs in an unrelated language (e.g., a Chinese query returning Japanese articles) — a plugin-version-gated defect, not a configuration issue. PRB20017014No published translation existing for the KB in the target language — Dynamic Translation cannot generate an answer from content that was never translated and published; this shows up as "no results" rather than a wrong-language result. Resolution 1Confirm the Now Assist in AI Search plugin (and the related GAIC / Now Assist in Virtual Agent plugins) are on a current version — the wrong-language response has known version-gated fixes.2If using Dynamic Translation with a customized provider, verify the translator configuration property points at the correct configuration record.3Check the Translated Versions related list on the source KB to confirm a published translation actually exists for the target language. If it doesn't, Dynamic Translation has nothing to return.4Enable glide.ais.translate.enable_global_language_fallback where an English fallback is acceptable while translations for the target language are still being completed.5Compare the retrieval trace for a working (English) request against the failing (target-language) request in the AI Search / Now Assist generative-AI log to confirm which KB and language were actually retrieved on each. ⚠️ Cross-language leakage — for example, a Chinese query returning Japanese content — is not expected behavior. If plugin versions are current and the target-language translation is published, treat this as a case worth opening with ServiceNow Support rather than a configuration gap. 📘 KB0963538 📘 KB1707148 📘 KB2539299 — Cross-Language Retrieval 🗄️ Use Case 10: Duplicate Translation Records Break Language Resolution I18N AI Search Problem Two different translated names for the same catalog item or KB resolve to the same underlying record, producing inconsistent or unexpected search results. Separately, English queries fail to fall back to available non-English content when no English version has been published. Root Cause 1Duplicate sys_translated_text records exist for the same language, both pointing at the same record's sys_id. Whichever translated string the search matches, it resolves to the same item — which looks like the wrong item was returned when in fact two names collapsed onto one record. PRB1920242 PRB20508872Global language fallback is disabled across the board — enable_global_language_fallback=false, global_fallback_locale empty, and glide.knowman.enable_multi_language_search=false — which blocks English-to-target-language fallback entirely. Resolution 1Query sys_translated_text for the affected table/field/language and look for more than one row resolving to the same sys_id: navigate to sys_translated_text_list.do and filter by language, table name, and field name.2Remove the duplicate row and keep a single, correctly-worded canonical translation.3Re-index the affected Indexed Source after de-duplication — translation edits are not reflected in search until the source is re-indexed.4If English-to-target-language fallback is also needed, set all three properties together: glide.ais.translate.enable_global_language_fallback=true, glide.ais.translate.global_fallback_locale, and glide.knowman.enable_multi_language_search=true. 💡 These three fallback properties operate as a set. Configure them together rather than one at a time — a single property left at its default can silently cancel out the other two. 📘 KB0142559 📘 KB1185030 — Translation Data Integrity 🧭 Use Case 11: Topic / Taxonomy Search Returns Zero Results for Non-English AI Search I18N Problem The AI Search Topic Search / Topic Content widget returns zero results for Spanish, French, German, or Japanese — even though the same search works correctly in AI Search Preview, and even after upgrading to a version where the underlying platform defect is fixed. Root Cause The widget matches against topic_path translations in sys_translated_text as an exact-match key. Three data problems produce the same symptom PRB1823459: 1Case mismatch — the widget searches for one casing (e.g. "Mis servicios") while the stored translation uses another (e.g. "Mis Servicios"). Capitalization and diacritics must match exactly.2Polluted translation — the stored topic_path value is worded or capitalized incorrectly (e.g. "Contratacion e incorporacion" instead of "Contratacion e Incorporacion"), which breaks the facet/index match on taxonomy topic pages.3Missing translation — no topic_path translation exists for that topic in that language at all, so the non-English topic widget returns nothing regardless of plugin version. Resolution 1Locate the topic_path translation: navigate to sys_translated_text_list.do?sysparm_query=language=<locale>^tablenameLIKEtopic^fieldname=topic_path.2Correct the case and accents so the translated value exactly matches what the widget searches for.3Create the translation where it is missing entirely for the failing topic.4Re-index the affected Indexed Source (Catalog Item / Knowledge) after the data fix — this step is mandatory; edits to sys_translated_text are not reflected in search until the source is re-indexed.5If you're still on an older release, also apply the current AI Search platform fix for topic search, then re-validate the data above — on a fixed version, a persisting failure is a topic_path data problem, not the platform defect. ℹ️ Reproduce first in AI Search Preview. If Preview returns the correct result but the portal topic widget does not, the issue is isolated to the widget/topic layer rather than retrieval itself. 📘 KB1649376 — Topic Search Non-English 📘 KB0610453 🔖 Use Case 12: Facet / Filter Labels Not Translated AI Search Service Portal Problem Topics/Subtopics facets, or standard filter labels such as "Hide filters", stay in English regardless of the user's session language — even though translations render correctly everywhere else in the portal. Facets can also appear in mixed languages, with some filters translated and others not, and a reference-field facet can occasionally return a translated value even when the session and topic are both English. Root Cause 1Facet/topic labels under Topics & Subtopics are not rendered from the translation table, even though the same translation renders correctly elsewhere in the portal — a known widget-rendering gap PRB1594577.2Facet-filter language failing to follow the user's preferred language is a separate, distinct defect with its own plugin fix PRB1925971.3Running an outdated or customized EC Search / Faceted Search widget blocks the fix from taking effect — the fix only applies once the portal is back on the current out-of-the-box widget.4Reference-field facets can source a translated value differently than String fields, which is why a reference-field facet can show a translated (e.g. Spanish) value in an otherwise English context while a String-field facet stays consistent PRB1824166.5A separate i18n gap leaves the standard "Hide filters" label untranslated PRB1516824. Resolution 1Revert any custom facet widget back to the latest out-of-the-box EC Search / Faceted Search widget before troubleshooting further — this is the most common blocker.2Confirm label translations exist in both sys_ui_message and sys_translated_text — a translation present in only one table will not fully resolve.3Add index_translated_fields to the search source, and set enable-label-translation="true" on the widget where supported.4Where the OOB widget still doesn't render the label from the translation table, apply the documented workaround (clone the OOB widget and add the missing HTML tag) or upgrade to the fixed plugin version.5For String facets where consistent language rendering matters more than dynamic translation, prefer a String field over a reference field. 📘 KB1205962 📘 KB1649376 📘 KB0727836 — Facet Translation 🧩 Use Case 13: Out-of-the-Box Portal Labels Not Translating Service Portal I18N Problem A handful of out-of-the-box portal fields or labels — for example, in a Portuguese (Brazil) deployment — are not translated even though the translation exists and other labels translate correctly. Separately, an option like forceNewTab stops working only when the language is not English, or a sub-topic display value renders in the wrong language. Root Cause 1The affected fields are missing the i18 prefix that is present out-of-the-box — without it, translations stored in sys_ui_message are never applied to that field, regardless of how complete the translation itself is. PRB1789111 PRB18038472Locale-specific handling in view/composite data templates can break non-English-only options such as forceNewTab, independent of the i18 prefix issue above.3A sub-topic display value is sometimes not sourced from the translation table at all, so it always renders in the base language rather than the user's session language. Resolution 1Compare the affected field's definition against an out-of-the-box instance and restore the missing i18 prefix so it matches OOTB.2Where the gap is a known platform defect for a specific language pack, apply the current fixed release for that defect.3For a broken forceNewTab (or similar) option in non-English, review and correct the view/composite data template rather than the translation records themselves.4For a mis-rendered sub-topic display value, confirm it is wired to resolve from sys_translated_text, correct the wiring, and re-render. 💡 When a translation clearly exists but doesn't render, diff the field definition against an OOTB instance before assuming the translation content itself is wrong — a missing i18 prefix is a common and easy-to-miss root cause. 📘 KB0963538 📘 KB1225665 — OOB Label Translation 🎯 Use Case 14: Language Detection Fails on the First or Switched Turn AI Search Now Assist VA Problem The first message a user sends to Now Assist Virtual Agent in a non-English language returns "not enough information" or an English-language answer, even though the same question works correctly on a later turn in the same conversation, or when asked again from a fresh session in that language. Root Cause 1Language Detection and Dynamic Translation are two separate toggles in Now Assist Admin. It's common to enable only one and assume the other is included — when Language Detection is off, the query language is never detected and dtTargetLanguage stays session-derived even with Dynamic Translation on.2A first-turn-specific detection gap exists on some versions: language detection works correctly from the second message onward but is skipped on the very first message of a session. PRB19203633The model can also over-generalize a non-English question as "a general procedural question that applies universally" and answer in English regardless of the detected or preferred language. Resolution 1In Now Assist Admin, confirm both Language Detection and Dynamic Translation are enabled — they are independent switches.2Upgrade to a current Now Assist / Virtual Agent plugin version for the first-turn detection gap.3Under Now Assist Admin > Languages, verify a translation provider (native or dynamic) is actively configured for each target language.4Where the model still over-generalizes to English despite correct detection, tune the skill/prompt to respect the detected language rather than defaulting to a general-purpose answer. ℹ️ Test the first message of a session explicitly in each supported language. Many detection defects only reproduce on that first turn and will look "fixed" if you only test follow-up messages. 📘 KB0123709 📘 KB2730107 — Language Detection 🗣️ Use Case 15: Dynamic Translation Not Applied to the Synthesized Answer AI Search Now Assist VA Problem A Multi-Content or summarized answer renders in English (or the wrong language) despite the user's session or preferred language, even with Dynamic Translation enabled. In German, a summary can switch between the formal "Sie" and informal "Du" register mid-answer. The same question can also produce different-language answers across repeated attempts. Root Cause 1The synthesis/summarization step computes its target language as metadata.contextLanguage || gs.getSession().getLanguage() — the query's own language is not separately detected, so dtTargetLanguage stays session-derived even when Dynamic Translation is enabled. This is a design gap rather than a configuration mistake, and there is currently no in-product toggle that resolves it on its own. PRB19983132Register switching (Du/Sie) is controlled by a setting called skipDefaultLanguageInstruction on the Synthesised Answer and Router components — disabling it stops the mid-answer switching. PRB18796803Differences in which underlying model is configured (e.g. a larger general-purpose model vs. a narrower one) change language adherence, and older GAIC / Now Assist in Virtual Agent plugin versions amplify the effect. Resolution 1For register/language switching mid-answer, disable skipDefaultLanguageInstruction on both the Synthesised Answer and Router components.2Upgrade GAIC / Now Assist in Virtual Agent / Configurations plugins where the instance is running an older build — language adherence has improved across versions.3Keep the same underlying model configured consistently across dev, test, and production so that language-adherence issues are reproducible rather than intermittent.4Confirm target-language translations exist and are published for the KBs and catalog items in play before expecting a translated answer — Dynamic Translation cannot invent content that hasn't been translated. ⚠️ The contextLanguage fallback-to-session-language behavior is a known design gap, not a bug with a simple property fix. If disabling skipDefaultLanguageInstruction and confirming plugin versions doesn't resolve it, treat this as a case to open rather than a missed configuration step. 📘 KB2558796 📘 KB0016066 — Synthesis Language Adherence 📍 Use Case 16: Country-to-Language Mapping Configured but Not Taking Effect AI Search ESC Portal Problem The ais_country_to_search_language mapping from Use Case 7 is configured, but users still see the wrong language set — for example, a German user receives Italian-indexed documents — and disabling an Improvement Rule that was suspected as the cause makes no difference. Root Cause 1Country-based language mapping depends entirely on the Country Code field on sys_user. When that field is empty, or the country isn't yet mapped in ais_country_to_search_language, AI Search falls back to searching the wrong language set for that user. PRB18920312In at least one observed case, the actual driver was relevance, not the country mapping or an Improvement Rule at all: a German-titled article legitimately matched the keyword in its title, so it surfaced for German users regardless of the country/language configuration. Rule out relevance before assuming the mapping itself is broken. Resolution 1Confirm the Country Code choice value exists for the affected country and is actually populated on the test user's sys_user record.2Confirm a matching row exists in ais_country_to_search_language for that country/language combination.3Test the change on the exact search profile the portal uses, not just the default Preview profile — Preview can silently use a different profile than production.4Before concluding an Improvement Rule or the country mapping is at fault, check whether the unexpected-language result is simply the most relevant match by title/content for that query. 📘 KB0161560 📘 KB0418820 — Country-to-Language Mapping 🎧 Use Case 17: Live Agent Transfer Fails Intermittently in Non-English Now Assist VA Multilingual Problem A user asks Virtual Agent to transfer them to a live agent using a non-English phrase (observed with Chinese) and the transfer intermittently does not trigger — the conversation continues with the bot instead of handing off, even though the same phrasing works on other attempts. Root Cause This has an observed pattern rather than a confirmed defect: the non-English transfer phrase is intermittently not recognized as a transfer intent, so connectToAgent never fires. The intermittency itself points toward language detection/translation timing on that specific utterance, but this has not been confirmed as the root cause and should be validated on your instance rather than assumed. Resolution 1Confirm Language Detection and Dynamic Translation are both enabled, and that the transfer phrase itself is mapped for the affected language (see Use Case 14 for the detection toggles).2Add or confirm representative non-English transfer utterances (e.g., common phrasings for "talk to a person" / "transfer me") so the intent has more than one phrasing to match against.3Reproduce with the exact conversation and message that failed, and compare it against a conversation where the same phrasing worked — check whether transfer intent was detected on one and not the other.4If the configuration above is already correct and the transfer still fails intermittently, open a case with the reproduction details rather than continuing to adjust language settings — this may be a defect rather than a configuration gap. ℹ️ Explicitly test the live-agent transfer phrase in each supported language rather than assuming it inherits from English behavior. Intermittent transfer failures are usually a language-intent gap specific to that phrasing, not a general Virtual Agent issue. 💼 Common Customer Scenarios & Quick Solutions Scenario A — Global company, English-only KBs, multilingual workforce Situation: A multinational organization maintains all KB articles in English. Employees in Germany, France, Spain, and Brazil need to search and find these articles in their native language via the ESC portal and Virtual Agent. Quick solution: Set glide.ais.global_searchable_filter.kb_knowledge to include all published KBs. This makes English articles discoverable regardless of the user's session language. Now Assist VA will retrieve the English article and respond in the user's language. Result: A German employee typing "Passwort zurücksetzen" finds the English password reset KB, and the VA responds with a summary in German. Scenario B — Dual-language KB portal (e.g., English + French Canada) Situation: An organization has KB articles in both English and French Canadian. French-speaking users should see French articles when available, and fall back to English when no French version exists. Quick solution: Enable glide.ais.translate.enable_global_language_fallback = true and set glide.ais.translate.global_fallback_locale = en-US. This returns articles in both the user's language AND English. Result: A French user sees French articles where they exist, plus English articles for topics not yet translated. Scenario C — Regional offices, each needing specific language combinations Situation: A European company has offices in Germany, UK, and France. German users should see German + English articles. UK users should see English only. French users should see French + English. Quick solution: Populate the Country Code on each user record, then configure the ais_country_to_search_language table with per-country language mappings (Germany → German + English, UK → English, France → French + English). Result: Each regional office sees exactly the language combination they need — no more, no less. Scenario D — Both translated and original articles appearing together Situation: An organization translated several English KB articles into German. Now both English and German versions appear in the KB listing for all users, regardless of language. Quick solution: Set glide.knowman.enable_multi_language_search = false. Ensure translated articles are linked via the Translated Versions related list. Verify each article's Language field is correctly set. Result: English users see only English versions; German users see only German versions. Scenario E — KB categories disappear when switching to non-English Situation: The KB Categories widget shows categories correctly in English, but when a user switches to German or French, the categories go blank. Quick solution: This is a known platform defect fixed in Xanadu Patch 2. Upgrade, or import the patched widget XML provided by ServiceNow Support as a workaround. Also ensure there are published articles in the user's language within the affected KB. Result: Category labels render correctly in all configured languages after the fix is applied. ⚙️ Key System Properties Reference PropertyEnginePurpose & Behaviorglide.knowman.enable_multi_language_searchZingWhen true: shows articles in ALL languages. When false (default): restricts to user's session language. Does not affect AI Search.glide.knowman.search.default_languageZingSets the default fallback language for Knowledge search (e.g., "en"). Used when multi-language search is disabled.glide.ais.translate.enable_global_language_fallbackAI SearchWhen true: AI Search returns articles in both user's session language AND the fallback locale.glide.ais.translate.global_fallback_localeAI SearchSpecifies the fallback locale (e.g., "en-US"). If not set, defaults to glide.system.locale. If that's also invalid, defaults to English.glide.ais.global_searchable_filter.kb_knowledgeAI SearchControls which KBs are included in AI Search results. Must include all relevant Knowledge Bases in the filter query.glide.knowman.enable_language_fallbackZingEnables fallback to articles in the default language when user's language version is unavailable.glide.knowman.translation.enable_translation_taskPlatformEnables automatic creation of translation tasks when KB articles are published.glide.system.localePlatformInstance-level locale setting. AI Search falls back to this when global_fallback_locale is not set.sn_generative_ai.append_lang_in_promptNow AssistAppends language to the LLM prompt for response generation. Affects how the LLM answers, not how AI Search retrieves articles. 📚 Consolidated Reference Links ServiceNow KB Articles 📘 KB0610453 — Translation Troubleshooting 📘 KB0952508 — AIS Troubleshooting Guide 📘 KB0965801 — Multi-Language Search 📘 KB0862447 — Default Search Language 📘 KB0861117 — Language Search Config 📘 KB2080419 — View Articles in Various Languages 📘 KB2238253 📘 KB1231502 📘 KB1337122 — Categories Widget 📘 KB1701107 — KB Categories Widget Known Error 📘 KB2687022 — Category Translation 📘 KB1638770 — Translation Config 📘 KB0755878 — Idea Management 📘 KB0997852 — AIS General Debugging 📘 KB0866478 — AIS Technical Overview 📘 KB0963538 📘 KB1707148 📘 KB2539299 — Cross-Language Retrieval 📘 KB0142559 📘 KB1185030 — Translation Data Integrity 📘 KB1649376 — Topic Search Non-English 📘 KB1205962 📘 KB0727836 — Facet Translation 📘 KB1225665 — OOB Label Translation 📘 KB0123709 📘 KB2730107 — Language Detection 📘 KB2558796 📘 KB0016066 — Synthesis Language Adherence 📘 KB0161560 📘 KB0418820 — Country-to-Language Mapping Product Documentation 📄 Enable Global Fallback Language (AIS) 📄 Configure Global Search for KB Articles 📄 Assign KB Search Languages by Country 📄 AIS Country to Search Language Form 📄 Configuring Dynamic Translation 📄 Localization Framework for KB 📄 Knowledge Management Properties 📄 AIS Result Improvement Rules 📄 Translation for Now Assist 📄 Enable Dynamic Translation for Now Assist Community & Developer Resources 🌐 Dev Share — AI Search Language Internationalization Workaround 🌐 Community — Enabling Multilingual Search with AIS (Utah) 🌐 Community — Global Language Fallback Article 🌐 Multilingual Support for Now Assist Products Multi-Language Knowledge Management: Diagnosis & Resolution Playbook