Adapting the product for a different language and region, text, formats, and layout, not just translating words.
Why it exists
A product that only speaks one language and assumes one culture shuts out everyone else, and translation baked into the code is unmaintainable. Localization exists to separate language and regional formatting from the code, so the same product can serve Bangla and English users without a rewrite.
How it actually works
Launching in Chattogram or abroad means more than swapping English for Bangla. Text length changes and can break layouts, dates and numbers format differently, currencies and units differ, and some languages read right to left. Localization is building the product so all of this adapts per region.
Done right, text lives separately from code so translations can be added without engineering rewrites, and layouts flex to fit longer or shorter text.
A senior PM walks you through it
A junior PM, stuck
The Bangla release shows the raw text checkout.cta_confirm on the payment button instead of a real label. The dev asked me to "check the strings file," opened two JSON files side by side, and I do not know what I am looking for or how a button ends up showing what looks like code to a customer.
That button is showing a key because its translation is missing, and the two files make it obvious once you know the pattern, so this is a five minute read. Below are the English and Bangla string files side by side. The app looks up text by key; when a key is missing in the active language, it prints the key itself, which is exactly the checkout.cta_confirm your customer saw.
en.json and bn.json, checkout strings (Bangla shown romanized)
en.json
1"checkout.title": "Checkout",
2"checkout.cta_confirm": "Confirm order",
3"checkout.cta_back": "Back to cart",
4"checkout.free_delivery": "Free delivery over 500 taka"
bn.json
5"checkout.title": "Checkout",
6"checkout.cta_back": "Carte fire jaan",
7"checkout.free_delivery": "500 takar cheye beshi mullyer ordare bina mule delivery"
Click a step to see the lines it points at.
Mistakes I've seen
Filing a raw key showing in the UI as a rendering bug for the engineers. It is a missing string in the language file; adding the key fixes it, usually with no code deploy.
Assuming a translation is done because the file exists. A file can be missing individual keys; the app silently falls back to the raw key on exactly those, so spot-check the important buttons.
Signing off Bangla copy on length alone without seeing it in the actual button. Bangla runs longer than English for the same meaning, so text that reads fine can still overflow a button built for the English width.
Treating localization as a one-time translation drop. Every new string added later needs the same key in every language file, or that screen shows a raw key in the languages that were missed.
Tell the dev: "The payment button shows the raw key because checkout.cta_confirm is missing from bn.json, so it falls back to the key name. Adding the Bangla string fixes it, no code deploy. Separately, the Bangla free-delivery text runs longer than English and overflows its button, so that one needs to flex. Can we add the missing key and widen that button?" You read two string files, told a missing translation apart from a layout issue, and named the fix for each.
Where a PM meets this
Localization is a real project, not a checkbox; scoping a new-market launch means budgeting for it properly.
Designing with localization in mind early (flexible layouts, no text baked into images) saves painful rework later.
Hear it in a meeting
"The German copy overflows the button, the layout wasn't built to flex."