Multi-language, multi-currency launches without price drift

A developer three weeks from an international launch had the same two-bedroom apartment on three pages: an English landing page, a Spanish one, and an Arabic one, each hand-built from a duplicate of the last. Sales dropped the price on the flagship unit, the kind of discount that erodes developer margin when ungoverned. Someone updated the English page. The Spanish page kept the old number, and nobody thought to touch the Arabic one, because it read right-to-left and lived in a different template. By the time a buyer in the Gulf forwarded the auto-generated brochure to her agent in Madrid, that one apartment carried a different figure on the site, in the PDF, and on the reservation form she had already started filling in.

That is not a rare bug. It is the ordinary result of building a multi-market launch the usual way: one hand-built page for each market, each an editable copy, each a place the number can quietly disagree with the others. The drift was baked in the moment one price needed typing into more than one page.

The currency switcher is the wrong thing to worry about

The instinct when a launch goes international is to treat it as plumbing. Bolt a currency switcher onto the listing, wire it to a live exchange-rate feed, detect the visitor's country, and let the page render whatever the buyer's home currency happens to be that morning. It feels buyer-friendly, and it demos well in a meeting.

The trouble is that a switcher wired to a live feed does not display a price. It generates one. Every refresh, every visitor, every market can produce a slightly different figure for a unit whose contract will name exactly one currency and one amount. The switcher automates the risk of a contradictory price and hands it to a rate that keeps moving while the buyer reads.

Multi-currency, done honestly, is a governance decision before it is a feature. The real question is which number the contract will name, and whether every localized surface reads from that one.

Language and price are different kinds of problem

Both usually get filed under one heading, "going international," as if they were two plugins of equal weight. They behave nothing alike, and that is the pivot the rest of this piece turns on.

Language wants coverage. Translate the whole experience: the interface, the unit descriptions, the call to action, the disclaimer. A clumsy translation is embarrassing but rarely expensive, so the instinct to spread it everywhere is the right one.

Price wants a single home. A given unit has exactly one correct value at a given moment, and the job is to make every page, brochure, and form show that value. Each additional editable copy is one more spot where the value can drift out of step. Fixing that is a question of where the value is stored.

Contract currency or the buyer's currency: pick a side

Here is the fork with no clean answer. On the reservation page, do you show the price in the contract currency, the one the buyer will actually pay in, or in their local currency, the one they think in?

Come down on the contract currency as the authoritative figure, with local-currency amounts shown only as approximate and clearly labelled. That mirrors the contract itself, which names a payment currency and usually an exchange-rate source such as a central-bank reference rate (sample currency clauses, Law Insider). So the convention to follow is a primary price, indicative conversions marked as approximate, and a plain note that a converter cannot be guaranteed current.

That position settles the question of a live rate versus a fixed one too. A marketing page generally should not live-convert the contract price, because an on-page rate is a snapshot that expires the moment it renders, and the deposit clears days later against whatever the rate is by then. And if you do show a local figure, let the buyer pick the currency rather than silently defaulting to a geolocated guess, which is wrong often enough (VPNs, expats, dual nationals) to be worth avoiding.

What Vinode's own international launches actually shipped

The assumed answer, multi-language plus multi-currency, is not what the real projects did. Take three international developments Vinode has built for, as they run on their live sites today.

Safa Al Fursan, in the Al Fursan district of north-east Riyadh, runs bilingual: English and Arabic, a left-to-right and right-to-left pair with a language toggle in the header. On the public zone pages, units show availability as sold or free, and no price or currency appears at all. The developer chose to withhold the number rather than publish and convert it.

Tropical Mirage, a beachfront development near Bayahibe in the Dominican Republic, offers English and Spanish through a language switch, with the Spanish version on its own path. No currency switcher. +Colonia, a large smart-city project near Colonia del Sacramento in Uruguay, ships in Spanish only.

Across all three the pattern holds: multi-language, with the price fixed or withheld, and no live multi-currency conversion anywhere. That was a deliberate choice, and for an off-plan launch it is often the right one. Localize the experience, and either fix the price or keep it off the public page until a buyer is in a conversation.

Number formats, area units, and right-to-left layout

Generic internationalization guides worry about strings. Real estate has a harder problem: the most important string on the page is a number, and localizing a number wrong changes what it means.

• Decimal and thousands separators. 1,000.00 in English and 1.000,00 across much of Europe are the same amount with the comma and period swapped. Get the convention wrong and a reader in the other locale can see a figure that looks off by three orders of magnitude. On a price, that is worse than a typo. It reads as a different apartment.
• Area units. A unit listed at 120 m² reads as cramped to a buyer who thinks in square feet and never converts it in their head (120 m² is roughly 1,290 sq ft). Show the unit the market expects, or show both, but never let a buyer silently misjudge value.
• Right-to-left layout. An English/Arabic pair does more than translate words. The layout flips. Price, floor-plan labels, and the reserve button all move, and a component that was never tested in RTL breaks in ways a spellcheck never catches.

None of these live in a translation memory. They are QA items, and they are the ones that make a correctly-priced unit look mispriced.

One unit record, priced once

The mechanism that actually prevents drift is boring, and that is the point. Keep one record per unit, priced once, with each language stored on that record rather than as a separate hand-built page. Bind every listing, brochure, and form to that record so a price change propagates instead of being copied.

Vinode's Back Panel is built this way. The CMS holds unit data, pricing, availability, galleries, attributes, and translations in one place, and data-bound listings read from it so surfaces stay in sync automatically. The auto-generated per-unit PDF pulls the current price from the same record, which is exactly the surface where a stale hand-typed number tends to get caught weeks too late.

The record does not invent a local-currency price or lock an exchange rate. What it guarantees is narrower and more useful: the price you decided on shows up identically everywhere, in every language. Retire the per-country duplicate page and the whole class of drift bugs goes with it.

The exchange-rate risk a page should disclose

There is a real buyer anxiety underneath all of this, and no widget fixes it. An off-plan purchase is paid in stages over months or years, so the exchange rate a buyer sees at reservation is not the rate they will pay at each milestone, or at completion. A live on-page converter quietly implies otherwise. It shows a confident local number for a cost the buyer's own bank will settle at a different rate on a different day.

The honest move is to name the risk in plain language. Buyers have their own ways to hedge currency movement, forward contracts among them, and that is a buyer-side decision the page can acknowledge without pretending to make it. A staged cross-border purchase carries real currency risk the same way it carries market and construction risk, and a page can disclose it in the same plain terms. A line that says clearly "the contract price is X; local figures are indicative and your bank's rate at payment will differ" reads more honestly than a number that looks precise and is not.

Single-market launches can skip the currency policy

If you are launching one development, in one market, in one currency, you do not have this problem, and you should not manufacture it. A domestic Polish project priced in złoty needs good translation and little else. Reach for a switcher only when you have real buyers thinking in genuinely different currencies, and even then reach for it last, after the number is decided.

The failure mode to avoid above all is bolting multi-currency onto a stack of duplicated per-country pages. That multiplies the drift, once per currency, on top of the copies you already could not keep in step.

Settle the authoritative price before shopping for a switcher

The order of operations is the whole argument. Before anyone evaluates a currency switcher, settle four things: which number is authoritative and where it lives; the currency policy (contract-currency figure, local amounts indicative and labelled); how FX risk gets disclosed in plain words; and how every surface binds to that record so a change propagates.

None of that requires a switcher, and all of it has to happen before one earns a place on the page. So the next move is concrete: settle which price wins, give it a single home in the record, and bind every surface to it. Shop for a currency switcher after that, if at all.