Internationalisation: multi-language, multi-currency, by construction
International operation is a construction principle, not a retrofit. Every user-facing string lives in translation catalogues with parity enforced at build time (a missing translation fails the build); amounts carry their currency and territories their country; tax is modelled per jurisdiction with its own components and rates; and times are stored in UTC and displayed locally, with working-day arithmetic that respects bank holidays.
What does the capability do?
It lets one platform serve an estate that crosses languages, currencies, and borders without forking the product.
- Catalogued copy, enforced parity. No user-facing string is hardcoded in a component; everything lives in per-language catalogues, and the build fails if any language is missing a key. A half-translated release cannot ship by accident.
- Currency as data. Charges and payments carry their currency rather than assuming one. Territories record their own country and currency, so a network spanning borders attributes and reports revenue correctly, which the franchise hierarchy depends on.
- Tax per jurisdiction. Tax is modelled as components and rates per jurisdiction with effective dates, so the right tax applies in the right place and rate changes are scheduled rather than scrambled.
- UTC inside, local outside. Times are stored in UTC and displayed in the viewer’s time zone. Commercial date arithmetic, such as Direct Debit notice days, is counted in working days with bank-holiday calendars applied.
- Brandable and translatable together. The same discipline that externalises copy externalises brand, so a localised deployment is a content and theming exercise on one codebase.
Why build-enforced parity is the detail to check
Most products claim multi-language support; the question is what happens when a developer adds a screen and forgets one language. In most systems the answer is a silent English fallback discovered by a customer. Here the answer is a failed build, which means the person who created the gap fixes it before anyone ships. Internationalisation that survives is internationalisation the toolchain enforces.
Why it matters
Networks grow across borders, and operators increasingly serve staff and customers whose first language is not English. A platform that treats languages, currencies, tax jurisdictions, and time zones as data lets that growth happen on one codebase, one audit trail, and one operational model, which is exactly the scaling story the platform is built around.
Frequently asked questions
How does the platform handle multiple languages?
Can different territories operate in different currencies?
How are dates and times handled across time zones?
More Platform capabilities
Audit and accountability: every change has a who, a when, and a why
How the platform records change: audit events on every entity, event-sourced financial history for charges, payments, refunds, and mandates, and flagged head-office interventions.
Data protection: masked fields, encrypted secrets, and GDPR by design
How the platform protects personal data: field-level masking enforced in the API, encrypted payment details, soft traceable deletion, UK and EU Azure hosting, and federated sign-in.
Roles and permissions: one model across every module
How the platform controls access: a module-and-action permission matrix enforced at the API, roles scoped from network to site, field-level masking, and federated sign-in.
See this working in a demo
Book a consultation and we will demonstrate this capability on the Platform accelerator, against your own scenarios.
Book a demo