Feature Request

On multilingual knowledge base sites, most interface text — search bar labels, feedback prompts, article header text, and more — can be translated through Localization variables. However, the filter placeholder text for the “Explore articles” control in the left navigation pane, used to filter the category and article tree by name, is not included in any existing localization accordion, so it always displays in a single fixed language regardless of the reader’s selected language. Add the “Explore articles” filter placeholder (and its accessibility label) as an editable field within Localization variables, for example under the existing Category manager or General accordion, so it can be translated per language like other left-navigation text. Benefit: Readers browsing a multilingual knowledge base see fully and consistently translated interface text throughout the navigation experience, with no single untranslated field breaking an otherwise localized interface.

If I search on (e.g.) "(DEFAULT)", I need to see instances with the parentheses. But the search renders instances without (e.g., "default"). Thanks.

In our previous docs portal, the full-text search form field allowed users to search only within a category that represents a full document. For example, let's say we have a custom metadata field called IsDocument and we set that to 1 for document-level subcategories, 0 or null for all other categories. Then the Search box could have a field labeled "In current document" that automatically restricts the search to the document-level category in the tree, or the user could X (dismiss) "In current document" to search the entire workspace(s). Thanks for considering this.

Customers managing multi-workspace knowledge bases need search behavior that automatically adapts based on context: global results across all workspaces when searching from the homepage, but workspace-scoped results when searching from within a workspace page. This context-aware scoping should apply to both standard search (Algolia) and Eddy AI search. The behavior would reduce user confusion from overlapping terminology and product names across workspaces while ensuring users see only workspace-relevant documentation.

This request was created on behalf of Raya. The ability to filter search results by category directly within the portal search would greatly improve the user experience, especially for teams managing large volumes of articles with similar titles. This enhancement would help users narrow down results faster and locate the right content more efficiently.

We would like to customize the breadcrumb text 'Search' visible on the advanced search results page. At this time, we couldn't customize this text using the localization variables or Custom CSS/JavaScript. It would be great, if we could customize it for each language. Thanks.

Currently searching for articles is available only within a certain workspace but narrowing down the search within a specific category/folder is unavailable. Since our team is using multiple Categories/Subcategories (example - different countries articles, global articles etc) we need this functionality available. This will improve the search experience and save time especially when we have a big number of cloned articles in multiple Categories. As a user I would not like to see them all in the search. Screenshot of current search options below, where Category level (Tree) should be added:

A lot of our content might appear inside of flow diagrams. I appreciate the AI Assistant is just a language model, it can't do calculations or surface images etc. But it'd be great if we could insert detailed alt text or metadata which the AI Assistant could use to surface results. E.g. Flow diagram with 19 steps User wants to know what they should do after step 16 Currently, the AI Assistant can't surface an answer. Even if we input text into the (150-character limited [or so] metadata field). 1) Could you empower the AI Assistant to search metadata to surface answers? 2) Could you massively increase the alt text? If there's a better solution to the above (e.g. an accordion item dropdown detailing the steps of the flow diagram), please let me know. Thanks!

When searching for a term, it should include glossary entries within the search results. In this way, if there is a synonym listed in a glossary term then it should show that term and provide a way for the reader to understand the correct term to use within this knowledge base.

Currently, in the Knowledge Base site search filter, users can refine results based on workspace and language. However, there is no option to restrict search results by category directly from this filter. The request is to introduce a category-level filter within the search UI, allowing users to limit search results to a specific category (or categories) without needing to use Advanced Search. Additionally, having the ability to retain selected filter preferences across searches would further improve usability.