Localization Is Not Translation: What Shipping a Second Language Actually Takes

Somewhere in most product roadmaps sits a line item that reads “add Spanish” or “launch in German,” sized like a content task: hand the strings to a translator, swap them in, done. Then the product ships and the German buttons overflow their containers, the date picker shows month-day-year to a market that reads day-month-year, and the pricing page quietly displays “$1.234,56” as if it were a European price. None of that is a translation problem. It’s a localization problem, and the two get conflated constantly because translation is the visible 20% of the work and localization is the invisible 80%.

Translation converts words. Localization makes a product behave correctly for a market — formatting, layout, legal defaults, cultural assumptions, and the technical scaffolding that lets all of that vary without forking the codebase. Treating the two as the same task is why so many “we support five languages” products actually support five vocabularies wrapped around one culture’s assumptions.

Where the Real Work Is

Text expansion breaks fixed-width UI. English is a comparatively compact language. German, Finnish, and Russian routinely run 30-40% longer for the same meaning; Macedonian and other Slavic languages aren’t far behind. A button sized to fit “Submit” will not fit “Потврди и продолжи” or “Absenden und fortfahren.” If your components have hardcoded widths or truncate with ellipsis, a second language doesn’t just look different — it looks broken, and the breakage lands hardest on your primary calls to action.

Pluralization is not a suffix rule. English gets away with one/many. Many languages have three, four, or six plural forms with different rules for what counts as “few” versus “many.” A translated string like "{count} item(s)" is an English hack, not a pattern that survives contact with Slavic or Arabic grammar. If your i18n library doesn’t support ICU MessageFormat or an equivalent plural-rules system, you will eventually ship grammatically wrong sentences to every non-English user, repeatedly, in every count-based UI string you have.

Dates, numbers, and currency are locale data, not translated strings. 12/09/2026 means December 9th to an American and September 12th to almost everyone else. 1,234.56 and 1.234,56 are the same number formatted for two different audiences. These aren’t things a translator fixes in a spreadsheet — they need to be generated by locale-aware formatting functions (Intl.DateTimeFormat, Intl.NumberFormat, or your framework’s equivalent) everywhere a date, price, or quantity renders, including inside emails and PDFs, which teams reliably forget.

URLs and routing need a real strategy before launch, not after. Decide once whether locales live under subpaths (/mk/...), subdomains, or separate domains, and whether URL slugs translate or stay shared. Shared slugs are usually the right call — they’re what let a page and its translation pair up cleanly for hreflang tags and a language switcher that doesn’t 404. Retrofitting this after search engines have indexed your original URL structure is expensive; get it right in the architecture, not in a migration ticket eighteen months later.

Legal and compliance defaults change per market. Tax display rules, required disclosures, cookie consent mechanics, and even what counts as an acceptable default opt-in vary by jurisdiction. A checkout flow that’s compliant in the US can be actively non-compliant shipped unmodified into the EU. This is the localization work most likely to get skipped because it doesn’t show up in a visual QA pass — it shows up in a regulator’s letter.

Machine translation is a first draft, not a deliverable. Automated translation has gotten good at grammar and bad at nothing in particular — which is exactly the problem, because the errors it does make are fluent and confident rather than obviously wrong. A native speaker with product context needs to review strings in situ, not in a spreadsheet, because meaning shifts with placement: a word that’s a neutral label in a list can read as a command or an insult in a button.

What This Means for Scope

If localization is genuinely a line item on your roadmap, size it like the systems work it is: pick an i18n library with real plural and formatting support before you write your first translated string, decide your URL and routing strategy at the architecture stage, and budget for native-speaker review as a recurring cost every time source copy changes — not a one-time pass at launch. A product that launches in one language and adds a second later should be built as if the second language were coming from day one, because retrofitting locale-awareness into hardcoded strings and fixed-width components is dramatically more expensive than building it in from the start.

The teams that get this right don’t ship “translated” products. They ship products that happen to be available in more than one language, and the difference is invisible right up until the day a competitor’s German button overflows and yours doesn’t.

PNK WORKS builds and maintains this site itself in English and Macedonian, and brings that same infrastructure to client products that need to work in more than one market. Start a project.