Dynamic Multilingual Configuration Guide
Basic principles
Validator of schema-dsl supports dynamically specifying the language during validation without the need for global switching.
core methods
Option 1: Specify language during validation (recommended)✅
This is the most recommended solution. There is no need to modify the global state and it supports concurrent requests.
1.1 Configuration when the application starts (loading all languages at once)
Use s.config to load all custom language packs at once when the app starts.
1.2 Switch languages directly during runtime (no need to reload)
1.3 Obtain the language from the request header (actual application scenario)
1.3 Parsing the Accept-Language header
Option 2: Temporarily switch language
Suitable for a few scenarios.
2.1 Use closures to save the original language
Option 3: Express/Koa middleware
Encapsulated as middleware to automatically handle language switching.
3.1 Express middleware (recommended)
Through one-time configuration of middleware, subsequent business code does not need to care about language parameters.
For a complete example, please refer to dynamic-locale.ts.
3.2 Koa middleware
Complete example
Express complete example
best practices
1. Centralized management of language packs
2. Supported language list
3. Cache validator
4. Error response standardization
Plan comparison
Recommended: Option 1 + Option 3 (Middleware Encapsulation)
FAQ
Q1: How to deal with unsupported languages?
A: Fall back to default language
Do not directly pass the original Accept-Language header to locale; common values in browsers will have q= weights, which should be parsed first and then rolled back.
Q2: Does it support dynamic loading of language packs?
A: Support
Q3: How to customize error messages for certain fields?
A: Use .messages() method
Related documents
Corresponding sample file
Example entry: dynamic-locale.ts
Description: Covers Accept-Language parsing, runtime locale selection, and validation entries for the same schema in different request languages.