Knowledge Baseintermediate

Markets vs. languages

Markets are regions (countries, continents, or "global") that let visitors filter content. Languages are the translation axis. They live on the same settings tab but answer different questions — geography vs. text.

4 min read

Markets vs. languages

Markets and languages sit on the same Settings tab and get conflated more often than they should. They solve different problems and you can use one without the other.

  • A language is the text customers read. English, Swedish, German. Articles get translated into each enabled language, and customers see the version that matches their browser.
  • A market is the region customers buy from. United States, Germany, Europe at large. Customers in different markets sometimes need different content — different return policies, different VAT explanations, different supported payment methods.

Languages handle “what does this article say?”. Markets handle “which article should this region see?”.

How they overlap

You can have:

  • Many languages, one market. A global product available in English, Swedish, and German. One set of articles, translated.
  • One language, many markets. An English-only product sold in the US and the UK, where returns work differently. Same language, regional content variations.
  • Many languages, many markets. A product available in three languages across five regions, where each region has some shared and some region-specific content.
  • Neither. One language, no markets configured. The simplest case — every article applies everywhere.

Most teams start with neither, add languages as they expand, and only reach for markets when regional differences become real.

What markets actually do in Atender

A market is an entry in the Enabled Markets list under Settings → Knowledge → Markets and Languages. The list always contains global. Beyond that, you add the regions and countries you operate in:

  • Global — The default. Always enabled, can’t be removed. Articles tagged global show everywhere.
  • Region — Europe, North America, Asia, Oceania, etc. Useful when policies span several countries but stop at a continent’s edge.
  • Country — United States, Germany, Sweden. Useful when a single country has its own rules.

When customers visit the public help center, a market filter lets them narrow down to the region that applies to them. The same retrieval pipeline that powers search and AI agents respects the market filter — so a customer browsing under “Germany” sees Germany-specific content, with Global content as a baseline.

What languages actually do in Atender

A language is an entry in the Languages subtab. Each language is either Active (visible to customers) or Disabled (hidden but preserved). Adding a language doesn’t change which articles exist — it adds a translation axis on top of every article you already have.

The default language is your source of truth. You write articles in the default; Atender translates them into every Active language using the AI translation pipeline. Customers see the translation that matches their browser’s Accept-Language header, with a fallback to the default when a translation isn’t available.

For the full mechanics, see Multi-language Knowledge Base.

When you don’t need markets

Skip markets entirely if:

  • Your product is the same everywhere you sell it.
  • Your customers don’t need to filter by region.
  • You’re starting out — markets add a UI dimension that’s only worth it once the content actually differs by region.

You can add markets later without rewriting anything; existing articles stay tagged as Global by default.

When you don’t need languages

Skip languages entirely if:

  • All your customers read the same language and you’re not planning to expand.
  • You’d rather ship great content in one language than mediocre translations in five.

Translation is a real cost — translation jobs use AI inference, and translations need spot-checking. Don’t enable a language unless you have real demand.

How they combine in retrieval

Under the hood, every embedding chunk in the KB is tagged with a marketId and a languageId. When a query comes in:

  • The asker’s market narrows the candidate pool to “global + this market’s content”.
  • The asker’s language picks the translated chunks for ranking.

A German customer browsing the Germany market gets German-language content scoped to Germany + global, ranked by relevance. A US customer browsing without a market filter gets default-language content across everything. The split is invisible to the customer — they just see results that look right for where they are.

Where to go next

Tags

ConceptIntermediate