Configure workspace and customer-facing languages

Separate workspace language, company languages, Agent answer language, and translated content so each audience sees the right text.

Humind has several language layers that solve different problems. A teammate can change the B2B workspace language, a company can enable supported languages, Guidance can optionally enforce an answer language, and customer-facing Knowledge or interface text may need its own translated content.

This guide explains those boundaries and provides a safe multilingual test plan. It avoids assuming that changing one menu automatically translates merchant-authored articles, product data, or every customer-facing label.

How this fits into Humind

Humind separates configuration, daily operations, customer data, and measurement so that each change can be reviewed in the right place. The navigation is permission-aware: two teammates in the same company may legitimately see different areas.

Treat configuration as a controlled workflow. Confirm the active company, make one coherent change, test the customer journey, and only then use the live channel. This makes unexpected behavior easier to trace and avoids mixing content, design, and deployment problems.

Before you start

Access: Any teammate can use available workspace languages. Company language and Agent behavior changes require the corresponding company settings or Agent configuration permission.

  • List the languages the company actually supports for content and operations.
  • Choose a default operational language and define who owns translations.
  • Identify which text comes from Humind, merchant-authored Knowledge, catalog data, and custom interface settings.

Step-by-step workflow

  1. Set your workspace language

    Use the language control in the Humind navigation or profile experience to change the B2B interface for your own session. This changes translated Humind menus and labels; it does not rewrite company content or force shoppers to use the same language.

    If a raw translation key appears, refresh after the language file loads and report the exact page and selected language. Do not edit Knowledge to compensate for a missing interface translation.

  2. Configure company languages

    Open Settings and the company language area. Review available and enabled languages and the default company context. Enable only languages the team can maintain and support across Knowledge, catalog, interface, and human handoff.

    For Shopify Markets, remember that each activated market can have its own Humind company context. Confirm the company and market before interpreting language or catalog differences.

  3. Choose Agent language behavior

    Open AI Agent, then Guidance. The answer behavior includes an option to enforce a custom language. When enforcement is off, test how the Agent responds to shopper language. When it is on, choose one of the currently offered languages and verify that this matches the business policy.

    Language enforcement affects response behavior, not the existence or quality of translated Knowledge. Keep source content accurate in every published language the company promises.

  4. Review merchant-authored customer text

    Audit Knowledge titles, excerpts, article bodies, Agent name and home text, entry-point button labels, chat invitations, survey or consent text, support channels, and any product text coming from the commerce platform.

    A Helpdesk publishes locale-specific snapshots. Only publish a locale when its visible collections and articles are ready. Internal links should point to stable localized routes rather than mixing languages in one page.

  5. Test each language end to end

    For every enabled customer language, run the same policy, product, support, and no-result scenarios. Check script direction, punctuation, links, product fields, consent, and the operator handoff. Ask a fluent reviewer to validate meaning, not only grammar.

    Repeat a small live smoke test after deployment. The storefront locale, selected Humind company, and Helpdesk locale must align for the result to be meaningful.

Permissions and important caveats

  • Changing the B2B workspace language does not translate merchant-authored Knowledge or catalog fields.
  • Enabling a company language should follow content and support readiness, not precede it.
  • Agent language enforcement is a behavior setting and can intentionally override the shopper's language.
  • Helpdesk locales are published snapshots; unfinished translations should not be exposed as complete content.

Verify the result

Use this checklist before considering the work complete:

  • Workspace, company, Agent, Knowledge, Helpdesk, and storefront language decisions are documented separately.
  • Every enabled customer language has reviewed public content and a support owner.
  • Product, policy, consent, invitation, and handoff tests pass in each language.
  • Internal Helpdesk links stay within the intended locale and do not expose unpublished content.

Troubleshooting

Menus change language but articles do not

This is expected when only the workspace locale changed. Translate and publish the merchant-authored content for the intended locale, then publish a new Helpdesk snapshot if applicable.

The Agent answers in an unexpected language

Review Guidance language enforcement, the shopper prompt, active company language policy, and source content. Start a new test conversation after changing enforcement.

A Helpdesk locale is empty or incomplete

Confirm that eligible public articles and folders have content for that locale and that the locale is included in the current immutable publication. Do not fill gaps with demo or another locale's content.

Related guides

Was this article helpful?