Principle:Langgenius Dify Internationalization Configuration
| Knowledge Sources | Dify |
|---|---|
| Domains | Frontend, Internationalization, Configuration |
| Last Updated | 2026-02-12 07:00 GMT |
Overview
Complete i18n infrastructure configuration for both client and server-side rendering with 23 locales and 30 namespaces, providing the foundational setup that enables multi-language support across the Dify frontend.
Description
The Internationalization Configuration principle defines the infrastructure layer that powers Dify's multi-language support. This encompasses the i18next initialization for both client-side and server-side rendering contexts, the language registry that maps locale codes to display names and fallback chains, the resource loading system that imports translation namespaces on demand, and the server-side translation utilities that enable localized content in server components. With 23 supported locales and 30 translation namespaces, the configuration must balance completeness with performance.
In the Dify codebase, the i18n configuration is split across several specialized modules. The i18n client module initializes i18next with browser-specific settings including language detection and resource loading. The i18n server module provides a parallel initialization for server-side rendering where browser APIs are unavailable. The language module defines the canonical list of supported locales with their metadata. The languages module maps locale codes to human-readable names for language selection UI. The resources module defines the namespace-to-file mapping that controls how translation files are loaded and bundled.
This principle matters because incorrect i18n configuration can cause a cascade of user-facing issues: missing translations, hydration mismatches between server and client renders, bloated bundles from eagerly loading all locales, or broken language switching. The split between client and server configuration is particularly critical in Next.js applications where the same translation keys must resolve correctly in both rendering contexts. A well-structured i18n configuration ensures that adding a new locale requires changes in exactly one place, adding a new namespace is straightforward, and the translation loading strategy minimizes performance impact.
Usage
Use this principle when:
- Adding support for a new language or locale to the Dify frontend
- Creating new translation namespaces for new feature areas
- Modifying the i18n initialization for client or server rendering contexts
Theoretical Basis
The i18n configuration follows the resource bundle pattern, where translations are organized into locale-specific bundles that are loaded based on the active language. The client/server split implements the isomorphic rendering pattern, providing environment-appropriate initialization while sharing the same translation resources. The namespace system follows the module federation pattern, allowing different feature teams to own their translation files independently. The fallback chain implements graceful degradation, ensuring that missing translations in a specific locale fall back to a more general locale before showing raw translation keys.