Feature Request

When users switch languages while viewing a Custom Page, they are redirected to the Docs home page or encounter a 404 error, even when the same Custom Page is published in the selected language. This happens because Custom Pages are treated as standalone pages and do not currently resolve based on the active language. Ideally, on language switch, the system should load the corresponding Custom Page in the selected language (if available), and only fall back to Docs home or 404 when it does not exist. Improving this would ensure a smoother and more consistent multilingual navigation experience.

Currently, the customer uses only one active documentation workspace with English (UK) and Swedish languages. However, an additional API workspace exists within the same project, which is not used by the customer and contains the default English (US) language. Since Custom Pages are created at the project level, the language dropdown in Custom Pages displays all languages across all versions, including the unused English (US) language from the API workspace. This causes confusion for editors, as the language is not relevant, not used, and not visible on the live knowledge base site. The customer would like the ability to hide or remove unused languages, especially those from API workspaces, from the Custom Pages language dropdown so that it reflects only the languages relevant to their active documentation workspace.

Now they just disappear and you have to restore from backup. They are handled differently than regular articles, this is confusing and inconsistent.

Since the current image isn’t customizable at the project level, the current version may create a poor user experience. Looking for options to customise the image.

The change is in the 'Meet the Team' section at the bottom of the front page. See attachment.

It would be great to have the possibility to create custom pages for different language versions in basic style.

We would like the header components, to remain visible when a 404 page is encountered, similar to how they appear on the documentation page.

The customer has requested an option to customize the error message displayed when attempting to self-register from a domain that has not been allowed.

Presently, we have the capability to customize error pages globally. However, having the option to customize error pages on a workspace level would be immensely beneficial, especially for managing different sets of customers/products across various workspaces.