Language & timezone wiring

The interface locale comes from the URL prefix. Every API call carries X-Locale and X-Timezone explicitly, and the server's answer is checked against Content-Language.

API base URL: http://127.0.0.1:8092
Interface locale (from the URL prefix): en
Server-resolved locale (Content-Language): en
Front/back locale check: ✓ Consistent with the interface
Locales the API supports: en, zh-CN, ja
Display timezone: Asia/Shanghai
Server time as returned (UTC): 2026-10-16T17:13:30Z
Rendered in the display timezone: Oct 17, 2026, 1:13:30 AM

What the server actually sent back

Everything else on this page is a front-end message (ICU). These two come straight from the API response — the front end does not translate them. Switch the language in the header and watch them change.

Finished copy rendered by the server (response body `message`)successRendered by the backend for this request's X-Locale — not a front-end string

Key response headers: Content-Language: en; X-Timezone: Asia/Shanghai; body.locale: en; body.timezone: Asia/Shanghai

Raw response body

{
  "code": 0,
  "data": {
    "status": "ok",
    "service": "fan-shop-api",
    "version": "dev",
    "started_at": "2026-10-16T16:55:07Z",
    "uptime_seconds": 1102,
    "time": "2026-10-16T17:13:30Z"
  },
  "locale": "en",
  "message": "success",
  "timezone": "Asia/Shanghai"
}

Experiment: force a mismatch on purpose

Pick what X-Locale to send and see which language the server actually renders in. Send an unsupported one and the server falls straight back to the source language — which is exactly why the front end must not send a value it cannot map.

Send X-Locale:

Shipping estimate

CategoryDestinationQuantity

Switching language keeps the deep path

Only the first path segment is replaced: /en/a/b and /zh-CN/a/b are the same page in two languages.