How I detected language by country with no manual switcher: the iFace Simulator case

The problem: explaining medical-aesthetic training models to different markets

iFace makes physical and digital training models so doctors can practice aesthetic procedures before operating. It needed a site that explained each simulator clearly and worked in multiple languages based on the visitor's country, without forcing them to pick a language by hand.

How each simulator is assembled: lazy-loaded routes, no central registry

There's no config array listing the available simulators. Each one is, literally, one lazy import() line plus one <Route> line in the router.

const R1   = lazy(() => import('./components/R1/R1'));
const Lips = lazy(() => import('./components/Lips/Lips'));
const INose = lazy(() => import('./components/INose/INose'));

<Route path="simulators/r1" element={<R1 />} />
<Route path="simulators/lips" element={<Lips />} />
<Route path="simulators/inose" element={<INose />} />
{/* Models */}
<Route path="models/discovery-model" element={<DiscoveryModel />} />

Adding a new simulator means adding these two lines, not modifying a module system. It's a simple architecture until the number of simulators grows a lot, at which point a data registry would probably be worth it.

How the site decides which language to show you

The site uses i18next with three complete translation packages: English, Spanish and Portuguese. There's no Italian, even though I speak it: the product specifically targets English, Spanish and Portuguese speaking markets.

import en from './locales/en/translation.json';
import es from './locales/es/translation.json';
import pt from './locales/pt/translation.json';

const resources = { en: { translation: en }, es: { translation: es }, pt: { translation: pt } };

i18n.use(initReactI18next).init({
  resources,
  lng: 'en',
  fallbackLng: 'en',
});

Which language to show doesn't depend on a switcher the visitor picks: a component geolocates the IP with ipapi.co and checks it against lists of Spanish and Portuguese speaking countries written directly in the code. If the country matches, it redirects to /es or /pt; otherwise it stays on /en.

It's not a space simulator platform: it's a store with a simple cart

Each product has a simple cart object, with id, name and price.

{
  cartId: 'r1-simulator',
  cartName: 'R1 Simulator',
  price: 344,
}

How I validated this architecture

I ran npm run build against the real repository (Vite 7, React 19) and measured the result instead of describing it from memory.

The build itself warned about a JavaScript chunk over 500KB (index-BEfQztCT.js, 560KB uncompressed), something worth splitting further if the site keeps growing.

A product's language is decided by its market, not by the biography of whoever builds it.

My part in this project

My part in iFace Simulator included frontend development, integrating Sanity as the CMS and the multilingual strategy, as part of my work at MANYA Digital.

What I'd do differently: a public description that didn't match the project

Before writing this article, this project's page on my site described a «space simulator platform» with a «real-time control dashboard». Reviewing the real repository, I found it's actually a marketing and e-commerce site for medical-aesthetic training models, with no dashboard and no real-time data of any kind. I've already corrected that description on the project page; I'm documenting it here because it's exactly the kind of mistake worth admitting instead of letting it slide.

What I'd test next

I'd verify there's a visible manual language switcher for when geolocation gets it wrong (a VPN, for example), and I'd split the 560KB JavaScript chunk the build flagged before the site adds more simulators.