That was my introduction to a truth every developer with global traffic eventually learns: internationalization is not a feature you add at the end. It is a set of assumptions you baked in on day one, and most of them are wrong for most of the planet. Here is what a small calculator site taught me about building for everyone.

1. Units are culture, not math

Americans think in gallons and inches. Almost everyone else thinks in liters and millimeters. This is not trivia, it is the first thing your international users notice. If your calculator defaults to gallons and your visitor from Berlin has to convert before they can even start, you have added friction before delivering any value.

The fix is to default by locale, not by your own habits. Detect the visitor's region, default metric for most of the world, imperial where it is actually used, and make switching one tap. In most of the world, nobody searches for gallons. They search for a cylinder volume calculator litres page, and the page that answers in their units wins before the calculation even starts.

Go one level deeper: meet the input where it lives. A German contractor types millimetres and expects litres out, not a lecture on unit conversion. That is why a dedicated mm to liters conversion exists as its own thing. The pattern generalizes to every tool app: do not make users translate their world into yours. Translate your app into theirs.

2. Number formatting will betray you

Here is a line of JavaScript that looks innocent:

const label = `Volume: ${volume.toFixed(2)} liters`;

In the US it renders "Volume: 1999.99 liters". In Germany the same user expects "1.999,99". In France, "1 999,99". In Egypt, the digits themselves change shape. Ship the hardcoded version worldwide and you will get confused emails from three countries in a week. I know, because I did.

The platform already solved this. Use it:

const fmt = new Intl.NumberFormat(userLocale, { maximumFractionDigits: 2 });
const label = `Volume: ${fmt.format(volume)} liters`;

Intl.NumberFormat handles separators, grouping, and digit shapes per locale. This deep dive on formatting numbers with JavaScript shows how far the API goes, including compact notation for large values. The rule I now follow: never hand-roll a number format string. If you are concatenating separators yourself, you are writing a bug with extra steps.

One more trap inside this trap: parsing. If a German user types "1.999,99" into your input and you run parseFloat on it, you get 1.999. Accepting localized input is the mirror image of localized output, and most tutorials only cover the output half. Validate against the locale you display, or normalize input to a canonical form before parsing.

3. RTL is not a mirror

Arabic and Hebrew readers read right to left, and supporting them is not a matter of flipping the layout like a pancake. The first version of my Arabic page just mirrored everything with a CSS transform. Text overlapped icons. The language switcher ended up under the thumb zone on mobile. Numbers inside Arabic sentences jumped to the wrong side.

What actually works:

Set both lang and dir on the document, not on a wrapper div. <html lang="ar" dir="rtl"> tells the browser, the screen reader, and the form controls what is going on. Everything downstream behaves better.

Use CSS logical properties everywhere. margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of text-align: left. One stylesheet then works in both directions, and you stop maintaining a separate RTL override file that rots.

Test with real text, not lorem ipsum. Arabic script connects between letters, needs larger line height than Latin at the same font size, and breaks if you apply letter-spacing. I learned each of those from a screenshot a user sent, not from documentation.

The deeper lesson: RTL support is a layout system choice you make on day one. Retrofitting it onto a codebase full of physical properties is weeks of work. Starting with logical properties costs nothing.

4. Let the locale choose, then let the user override

Detecting locale sounds simple until you do it. The browser sends Accept-Language, which is a ranked list, not a single value. The user may have set a preference in your app last visit. Their IP says one country and their browser says another language. Which wins?

My order now: explicit user choice first, stored in localStorage. Then Accept-Language. Then a sane default, never the developer's own locale as an accident. And the switcher must be visible without scrolling, labeled in each language's own name. Nobody looking for العربية wants to decode a dropdown that says "Arabic" in Latin script.

For the implementation side, the ecosystem has this covered. This step-by-step Vue i18n guide walks through locale detection, message loading, and persistence in a real app, and the patterns transfer directly to React or anything else. The architecture matters more than the library: locale as document state, translations as data, switching without a full reload.

5. Dates, timezones, and the long tail of locale bugs

Numbers and text direction get all the attention, but the long tail of locale bugs is where users quietly give up. Dates first: 03/04/2025 is March 4th in the US and April 3rd almost everywhere else. If your app shows a "last calculated" timestamp or a changelog date in a hardcoded format, half your users read it wrong. Intl.DateTimeFormat exists for exactly this, and like its number sibling it costs one line to use.

Timezones are the next trap. A user in Karachi and a user in Chicago see different "today" values. If you ever store or display a date, store UTC and render in the user's zone. This sounds like backend advice, but frontend developers hit it constantly in anything with history, scheduling, or "recently used" lists.

Then there is the category of bugs that no checklist catches because they are cultural. In some locales, users expect results rounded to friendly numbers. In others, showing too many decimals looks untrustworthy rather than precise. Pluralization rules differ wildly: Arabic has six plural forms, Japanese barely uses plurals at all. If your result label says "3 results" via string concatenation, it is wrong in more languages than it is right in.

The honest way to find these is to watch real users. I keep a small habit now: once a month, I open the analytics, filter by a country I know nothing about, and click through the site as if I lived there. Every session surfaces something embarrassing. It is the cheapest QA process I have, and it only works because the data tells me where to look instead of my assumptions.

6. Translate intent, not just strings

Here is the mistake I almost made with that Arabic page. My first instinct was to translate the English strings and call it done. But Search Console showed the Arabic queries were not translations of the English ones. They were different questions, with different volumes, asked by people with different needs. A translated page answers the wrong questions fluently.

So the real work was not translation, it was localization of intent. Which queries exist in this language? What units do these users expect? What does the competition look like in this locale? The Arabic page that won was not a mirror of the English page. It was built for its own audience from the query data up.

If your analytics show demand in a language you do not serve, do not admire the numbers. Serve it. And serve the intent, not just the words.

Takeaway

Internationalization breaks into five engineering decisions: default to the user's units, format numbers and dates with the platform APIs, build RTL in from day one with logical properties, detect locale in the right priority order, and hunt the long tail of cultural bugs with real user data. Then do the harder product work: find out what each locale actually wants, instead of translating what you wanted. The traffic is already there. It is just waiting for someone to meet it halfway.