Building a website that actually speaks two languages
Most "multilingual" websites are one language with a translation plugin taped on. The English version is the real site; the Persian version is an afterthought that breaks every time a developer ships a new feature without remembering to wire up the second language field. Fanpino CMS was built backwards from that pattern: every content model — articles, products, services, projects — carries en and fa fields side by side from the schema up, so there is no "primary" language to forget the other one.
Why bolting Persian onto an English CMS breaks down
Persian isn't just a translated string — it's right-to-left, it needs its own typography, and it usually needs its own currency and pricing logic too. Plugin-based i18n on WordPress or a headless CMS not designed for RTL from day one tends to solve the text problem and quietly ignore the layout and pricing problem, which is where the real support tickets come from.
How Fanpino CMS handles it
- Native RTL/LTR switching — the layout direction flips with the language, not just the text alignment.
- Dual currency pricing — USD and Toman are both first-class fields on every product, shown automatically based on the visitor's language.
- One admin panel, two languages — editors fill in both language fields in the same form, so nothing gets published half-translated by accident.
Built on a stack meant to be extended, not just used
The backend is FastAPI (Python); the frontend is React 19 with full TypeScript coverage. Authentication supports both JWT and Google OAuth2, with role-based access control for teams that need more than one admin. None of this is exotic — it's a deliberately boring, well-documented stack so a development team inheriting the codebase isn't starting from zero.
Who this is actually for
Teams serving both Persian-speaking and international audiences from a single site — without maintaining two separate codebases, two separate admin panels, or two separate mental models of "what's published where."
