Localization is not translation: a region's language, money, time and habits

When people ask to "make the app work in several languages," they usually picture translation: take the labels and swap them for another language. But a person is more than the language they read in. They carry a whole set of habits by which they recognize what is "theirs": how a date is written, where the separator sits in a number, what units measure distance, which currency shows the price, which day a week starts on. Translate only the labels and you get an app that is formally in their language yet still feels foreign.

True localization means matching a person across all of these habits at once. Below is the full list of what "making it multilingual and multiregional" actually involves, not just translating the buttons.

Text is more than labels

• Interface translation. All labels, tooltips, emails, errors - the obvious part, where it all begins.
• Translating the data itself. Statuses, categories, country and region names must read in the user's language too, not just the labels around them. Half the screen in your language and the data inside it in another - and the "translated in a hurry" feeling never goes away.
• Plurals. Languages have different rules: English has two forms (1 item / 5 items), Slavic languages have three or more (1 деталь / 2 детали / 5 деталей). A naive "item(s)" gives the machine away instantly.
• Text length. A German phrase can run almost a third longer than the English one, while another comes out shorter. The layout has to stretch to fit the text, not break or clip words.
• Sort order. The alphabet is a local thing: in one place "ё" is a separate letter, in another diacritics and letter combinations change the order. A list sorted "the way it sits in the database" looks random in another language.
• Writing direction. Arabic and Hebrew are written right to left - this is not "one more translation" but a mirror flip of the entire layout.

Numbers, money and units

• Number format. 1 234,56 or 1,234.56 - which thousands and decimal separator. The same number written in an unfamiliar way is read with a stumble.
• Units of measure. Distance (kilometers or miles), volume (liters or gallons), weight, temperature (°C or °F). An American thinks in miles and Fahrenheit, a European in kilometers and Celsius; each should see their own.
• Currency - and here is a subtlety that is easy to get burned on. The format of a currency (the symbol, its position, the number of decimals) is always localized. But converting amounts must be handled with care:

Time

• Formats. Date (09.07.2026 versus 07/09/2026), time (24 hours versus 12 with AM/PM), the first day of the week (Monday or Sunday - calendars and reports are counted from it).
• Time zone. A moment in time is stored internally in a single universal time and shown to each person in their own zone and format; exact universal time stays at hand throughout. There is a separate note about this.
• Relative time. "2 hours ago," "yesterday," "in 3 days" - this too is text, and it is translated together with the plural rules.

How the system guesses the region

• Detection on the first visit. The browser already knows which languages a person reads, which zone they are in, how dates and numbers are written in their system. It is reasonable to read these hints and offer ready-made values, rather than greeting a new user with a form of ten settings.
• The user's choice always wins. As soon as a person changes the language or format themselves, their decision is remembered and from then on outweighs any browser signals. The hint is for those who have not chosen anything yet.
• Whose choice it is. Sometimes language is a personal setting for the user, sometimes it is shared across the whole company or site. It is worth deciding in advance whose habit takes precedence and what is used by default.
• Fallback. If there is no translation for some text in the required language, the system shows it in a fallback language, not a blank or a placeholder key.

The engineering discipline underneath

Three things without which everything above falls apart:

• A single source of truth for translations. The texts live in one place, and what the browser loads is assembled from them automatically. Otherwise the trap: you fix a translation in the already-built file, and the next build overwrites it - as if the translation was never there.
• Store the canonical value, format at the edge. Internally there is one canonical value: time in a single zone, an amount in its own currency, a quantity in base units. The familiar format is applied at the very last moment, on the screen. Then the calculations stay exact and everyone sees their own.
• Region is a foundation, not a patch. If language and formats are built in as separate settings from the start, a new language or market is a matter of adding a layer, not rewriting the app. Bolt translation on afterward and you pay by redoing everything you managed to tie to a single language.