Internationalization

The Kit is fully internationalised. Every string flows through Lingui, every catalog is tree-shakeable per locale, RTL direction auto-derives from the active locale, and you can override individual messages without forking a translation file.

import { StridgeProvider } from "@stridge/kit"
import { messages as fr } from "@stridge/kit/i18n/locales/fr"

<StridgeProvider
  gatewayKey={process.env.NEXT_PUBLIC_STRIDGE_GATEWAY_KEY!}
  asset={{ networkId: "9001", symbol: "USDC" }}
  flows={{ deposit: { destination: { address: userWallet } } }}
  i18n={{ locale: "fr", messages: { fr } }}
>
  <App />
</StridgeProvider>

How `i18n` works on the provider

i18n?: {
  locale?: string
  messages?: Record<string, KitMessageCatalog>
}

locale — BCP-47 code ("en", "fr", "ar", "fa-IR"). The Kit normalises the language portion to pick the matching catalog.
messages — a map of locale code → catalog. Pass the catalogs you want active; the Kit mounts them at runtime.

If messages doesn't include the active locale, the Kit falls back to the source keys (English text the strings were authored against), so a missing catalog is a soft failure rather than a UI break.

Locale imports

Shipped locales live at @stridge/kit/i18n/locales/<code>. Each subpath exports a messages object — load one only if you actually need it:

import { messages as en } from "@stridge/kit/i18n/locales/en"
import { messages as es } from "@stridge/kit/i18n/locales/es"
import { messages as fr } from "@stridge/kit/i18n/locales/fr"
import { messages as de } from "@stridge/kit/i18n/locales/de"
import { messages as ar } from "@stridge/kit/i18n/locales/ar"
// … additional locales the Kit ships under `/locales/`

Pass them on the provider:

<StridgeProvider
  i18n={{
    locale: currentLocale,
    messages: { en, es, fr, ar },
  }}
>

Only the locales you import end up in your bundle.

RTL support

The Kit auto-derives direction: "rtl" for these locale prefixes:

Locale prefix	Language
`ar`	Arabic
`fa`	Persian
`he`	Hebrew
`ur`	Urdu

When direction is RTL:

The provider sets dir="rtl" on the scope root.
A data-stridge-flip-on-rtl attribute on chevrons / arrows triggers a transform: scaleX(-1) so iconography reads correctly.
Form layout flips logically — recipient / amount / receive columns rearrange via CSS logical properties (no hard-coded left / right).

You can override direction explicitly via appearance.direction, but the auto-derivation is correct for every shipped locale.

Custom message overrides — `defineMessages`

When you want to override a handful of strings — your app calls a thing differently, your tone of voice diverges, your locale isn't shipped yet — use defineMessages rather than rewriting a full catalog:

import { defineMessages } from "@stridge/kit/i18n"

const customFr = defineMessages({
  "deposit:method-wallet": "Dépôt par portefeuille",
  "deposit:method-transfer": "Virement",
  "withdraw:success-headline": "Votre retrait est en route",
})

<StridgeProvider
  i18n={{
    locale: "fr",
    messages: { fr: customFr },
  }}
>

defineMessages accepts a { [key]: string } map and returns a catalog the provider mounts directly. Keys you don't override fall back to the source-key English text.

You can compose: start from a shipped catalog, merge in custom overrides:

import { messages as fr } from "@stridge/kit/i18n/locales/fr"
import { defineMessages } from "@stridge/kit/i18n"

const customFr = defineMessages({
  "deposit:method-wallet": "Dépôt par portefeuille",
})

const mergedFr = { ...fr, ...customFr }

<StridgeProvider i18n={{ locale: "fr", messages: { fr: mergedFr } }}>

Reading translated strings from your own components

Components inside the Kit's scope can use the standard Lingui hooks the Kit re-exports:

import { useT, Trans, useKitI18n } from "@stridge/kit/i18n"

function YourBranding() {
  const t = useT()
  return <p>{t("Your funds will arrive on Arbitrum.")}</p>
}

useKitI18n() gives access to the active I18n instance for ad-hoc formatting (currency, dates) when the format helpers aren't enough.

Locale-conditional styling

Pair i18n.locale with the data-stridge-locale attribute the provider writes onto its scope to apply per-language CSS:

[data-stridge-locale^="fa"] {
    --stridge-kit-font-sans: Vazirmatn, sans-serif;
}

[data-stridge-locale^="ar"] {
    --stridge-kit-font-sans: "IBM Plex Sans Arabic", sans-serif;
}

That's how production integrations swap fonts for Persian, Arabic, Hindi, etc. without rebuilding the Kit.

Adding an unsupported locale

If the Kit doesn't ship a locale you need, use defineMessages to author one in your app:

import { defineMessages } from "@stridge/kit/i18n"

const tr = defineMessages({
  "deposit:method-wallet": "Cüzdan ile yatır",
  "deposit:method-transfer": "Banka havalesi",
  "withdraw:success-headline": "Çekim işleminiz yolda",
  // …
})

<StridgeProvider i18n={{ locale: "tr", messages: { tr } }}>

Send us a copy when you're done — we'll fold it into the shipped catalogs.

Provider — the i18n prop reference.
Theming & CSS variables — locale-conditional fonts.
Data attributes & slots — data-stridge-locale for script-specific CSS.

Was this page helpful?