Table of Contents

Localization

CodeBlock DevKit is built so your SaaS can speak more than one language. You decide which languages matter for your product—you can ship a subset or add more over time. The template’s sample appsettings is aligned with languages DevKit already anticipates well: English (typical default), Persian, Spanish, German, French, Portuguese, and Arabic. Those are reference cultures for layouts, fonts, and direction (LTR/RTL); you are not required to enable every one.

Visitors and operators pick a language where your UI exposes a switcher, and you keep translations in resource files and configuration instead of scattering magic strings through the codebase.

Each web client in the SaaS template (WebApp, AdminPanel, Api, and so on) carries its own appsettings.json. That is where you declare supported languages, defaults, and per-language branding (name, URLs, logo, support email, fonts, and reading direction). You do not need to wire the framework by hand first; start from the JSON your host already loads.

Dynamic per-language content in DevKit modules

This layer goes further than files and config: several core modules let you store different values per language in the database (for example payment or identity-related options). In the Admin Panel, operators choose a language from the same language picker they use elsewhere, then create or edit module content for that culture; they switch to another language and repeat. On the public site and in the user panel, visitors see whatever was saved for their active language—the same mental model as static resources, but editable at runtime without redeploying. Today this pattern is prominent in the Pricing and Settings modules; other modules may follow the same idea as they grow.

Where to go next

  • Configuration — What the Localization and Application sections mean, and what each field is for.
  • Services — Which settings types are injected into Razor, Blazor, and backend code, and how IStringLocalizer fits in.
  • Tutorials — Walkthroughs for wiring localization to your needs: configuring hosts, using settings in UI and code, resources, APIs, branding, admin-managed module content per language, and edge cases you might hit as you grow.

Together, those pages should give you a path from “we need English + Spanish” to a configured, branded, and translatable app on top of the template.