Table of Contents

Configuration

If you have not read it yet, start with Introduction for the big picture.

When you ship in more than one language, almost everything funnels through two blocks in each web client’s appsettings.json (for the public site, that is usually WebApp/appsettings.json). You do not need to touch framework wiring first—think of it as answering two questions for your product:

  1. Which languages exist, how is one chosen, and how should text look (direction, typeface)? → the Localization section.
  2. What is this product called, where does it live on the web, who do customers email, and what logo or landing URLs apply for each language? → the Application section.

The examples below mirror what the SaaS template ships; rename values to match your brand and domains.

Localization — languages visitors can pick

Option What it is for
CookieName Name of the cookie that remembers the visitor’s last chosen language. Change it if you run several apps on the same host and do not want cookies to collide.
Languages The list of languages shown in the language switcher and accepted by request localization. Each entry is one row in the UI.

Each language row supports:

Field What you put there
Name Human-readable label in your admin or language list (for example “English”, “فارسی”).
Code Culture code used everywhere else: .resx satellites, Application:Localizations keys, and the values API clients should align with when choosing language (see Tutorials — API calls). Keep it consistent with how you name resource files (en, fa, es, …).
ShortName Short label for compact UI (for example “En”, “Fa”).
Direction ltr or rtl so layouts and <html dir="…"> follow the script direction.
Font Whatever you want in CSS font-family for that language (see Tutorials — Pick typefaces with the Font field for @font-face plus matching appsettings samples).
IsDefault Exactly one language should have true: the language for new visitors who have not picked another yet, and the baseline for related defaults described in Tutorials.

Application — brand and URLs per language

Here you describe the product, not individual page strings (those stay in .resx files).

  • Default — your baseline for every culture. Always fill this.
  • Localizations — optional overrides keyed by the same Code values you used under Localization:Languages. Each entry uses the same property names as Default: you only repeat what should change for that culture; anything omitted keeps the value from Default.

Supported properties on Default and on each Localizations entry:

Property Purpose
Name Product or site title (headers, splash, metadata).
Description Short description (for example <meta name="description">).
Url Canonical public site URL for this language or region when it differs.
StaticUrl Base URL for static assets when it differs from Url; if you leave it out, it falls back sensibly from Url.
SupportEmail Contact address shown in footers or legal pages.
LogoUrl Path or URL to the logo image for this culture (for example /images/logos/logo-en.png vs /images/logos/logo-fa.png). If a culture block omits it, the Default logo is used.

At runtime your UI reads ApplicationSettings.Localized, which already merges Default with the block for the current culture.

Practical tips

  • Keep Localization:Languages and Application:Localizations in sync — if you add a culture to one side, add the matching Code on the other when you need different branding or URLs.
  • AdminPanel, WebApp and Api have their own appsettings files; copy the same language Code values if you want one mental model across hosts.
  • Step-by-step recipes (single-language site, fonts, logos, API headers) live in Tutorials; using the bound types in code is covered in Services.