The second locale gets blamed for the first locale's debt
An English-only product can pass every test while its architecture borrows from English. The bill appears when another language arrives, so the language is blamed for a debt it only exposed.
The first locale is a weak test
An English-only product can pass every test it has. Every label fits. Every date looks familiar. Every sentence assembled from fragments reads in the intended order. Left means the side the designer meant, and a name fits into the two boxes the form gives it.
This is why internationalization debt is easy to carry. The first locale does not exercise the property that is missing. It confirms that one language works under the assumptions made for that language, which is the same evidence the team already had before the test ran.
The W3C separates the two decisions. Internationalization is the design and development that enables later adaptation. Localization is the adaptation for a particular market 1. The distinction is not who performs the work. It is when a constraint enters the product.
A product can therefore have no localization and no localization defect. It can also have no internationalization and a large body of debt. Nothing contradicts until a second locale arrives. Then the messenger gets the bill.
Two decisions are hidden inside one budget line
Most roadmaps place both decisions on one line called “localization”. That line contains translation, review, support, market research, release coordination and the engineering work required to make any of them possible. The visible part recurs with every locale. The hidden part compounds inside the product.
| Decision | Cost behaviour | Deferral |
|---|---|---|
| Translate product copy | Recurs by locale and source change | Often rational until demand exists |
| Staff language support | Recurs while the market is served | Rational until the service promise is made |
| Separate messages from code | Touches each message once; retrofit surface grows with the product | A debt decision, not a translation decision |
| Use locale-aware formats and grammar | Cheap at a shared boundary; expensive after assumptions spread | A debt decision, not a locale purchase |
| Run pseudo and direction tests | Reusable engineering control | Does not require a translated product |
The combined line makes a sound refusal travel too far. A team decides not to fund French translation before French demand exists. The same decision quietly postpones message extraction, locale-aware formatting and expansion testing, even though none of those requires a French translator.
We have already made the market-timing case in the post on whether to localize before the first overseas customer. Usually, you do not need to. That conclusion becomes expensive only when it is applied to the architecture as well.
The product keeps working while the debt grows
Ordinary debt makes something worse now. A slow query is slow. A flaky test fails. Internationalization debt can leave the current product completely unchanged. A hard-coded label still renders. An English sentence built from three strings still reads as English. A fixed-width button still contains the word it was sized around.
The platform may already provide the missing boundary. Android tells developers to keep interface content in resource files and explicitly says not to hard-code strings. A localized resource can then be translated and integrated without a change to compiled code 2. Ignoring that boundary does not break the default locale. It makes the next one a source-code migration.
This invisibility distorts prioritization. The cost of prevention is booked against a hypothetical future market. The cost of the shortcut is absent from the current release because the one test capable of observing it has not been added. A green default-locale suite is then used as evidence that there is no problem.
A second locale exposes failures it did not create
A second locale changes the inputs. It does not create the assumptions that fail under them.
A 2020 study ran 31 open-source Android applications after translating their English interfaces into seven languages. The size of the problem was measured directly. The authors found 21,744 hard-coded strings across the applications, with at least one in every app. In 29 apps, at least one of the seven target languages had no translated resource file 3.
The GUI comparison recorded 333 collateral layout changes and 77 bugs. The bugs included 38 failures to mirror for right-to-left languages, 29 overflows caused by text expansion, eight overlaps and two lost components 3. A Portuguese label moved buttons. Arabic text overlapped an icon. Hindi labels removed alignments that held in English.
This is a study of a selected open-source Android sample, and its translated applications were produced for the experiment. It is not a population estimate for mobile software. It establishes the narrower point this argument needs: the default interface can conceal code and layout defects that become observable only when language changes.
Calling those localization bugs assigns them to the event that revealed them. The hard-coded string existed before the translation. The fixed constraint existed before the longer label. The physical direction existed before Arabic. The second locale supplied the test case, not the defect.
The retrofit estimate becomes an argument for more delay
Once the hidden work has accumulated, the first retrofit estimate is large. That estimate is then read as the cost of the new locale. The locale loses its business case, the work is postponed, and another release adds assumptions to the same surface. The next estimate is larger for reasons the postponement itself helped create.
State Street published an extreme but useful endpoint. HOLLANDER was a financial system from the 1990s with more than five million lines of C and C++ across 30 modules. Internationalizing and localizing it took two years, 25 developers and eight QA staff 4.
The team identified 504,000 lines that needed modification. Its purpose-built tools automatically converted 402,000 of them, or 79.76%, while the remainder still needed analysis and manual work 4. The system then needed resource extraction, a Chinese resource library, GUI adjustment and three kinds of testing.
One financial system is not a retrofit price list. Its age, language, scale and architecture are specific. The case shows the shape of the cost. The translation was one step. Most of the project changed the product that the translation had exposed.
A market decision is therefore made against two costs at once: the honest ongoing cost of serving the market, and the accumulated cost of making the product capable of serving it. Only the first belongs to the locale. Combining them makes an old architecture look like weak new demand.
The debt belongs to every team and therefore to none
The debt also survives because no single owner sees its complete balance. Engineering owns the resource boundary. Design owns the layout system. Product decides whether another market matters. Marketing sees acquisition copy, support sees language demand, legal sees a document obligation, and a translation vendor sees only the strings that arrived.
Each group can make a locally defensible decision. Engineering will not build a platform for a market that is absent from the roadmap. Product will not place a market on the roadmap while its entry cost is high. The vendor cannot lower that entry cost because it does not own the code that created it. The circle closes without anybody choosing the result.
The timing bias is not unique to localization. In one technical-debt experiment, 33 developers from two companies chose between immediate feature work and a longer-term architectural investment. The authors found widespread temporal discounting, with substantial differences between individuals 5. Applying that result to internationalization is an inference, not a measured cause of localization neglect. The shape of the choice is the same: a cost in the present competes with a benefit whose date and size remain uncertain.
Fragmented ownership makes the future benefit less visible again. Avoided retrofit work never appears as revenue in one team’s quarter. A shipped feature does.
Localization may wait; the debt still needs a reason
Deferral is not automatically neglect. A decision can be rational even when it creates debt, provided the saving is real, the exposure is understood and the assumption has an end.
| Product condition | Localization | Internationalization debt |
|---|---|---|
| Disposable prototype with an enforced deletion date | Defer | Usually acceptable because the code has no future option to preserve |
| Retiring legacy module | Defer unless an obligation applies | Often acceptable when replacement arrives before another locale |
| Controlled workforce with one operating language | Often defer | Record the workforce assumption and protect shared data boundaries |
| Single-market product with an uncertain future | Defer pending demand | Preserve cheap option value in messages, formats and reusable layout |
| Named expansion market or repeated customer demand | Test the smallest useful surface | Active debt with a present repayment trigger |
The fourth row matters most. A startup can decline to operate in six languages without hard-coding English grammar into every message. It can decline translation while retaining locale-aware number and date APIs. It can delay right-to-left support while keeping physical left and right out of reusable layout primitives.
Pseudolocalization exists for exactly this separation. It verifies that a product is localizable without translating it into a real language. It can reveal unexposed resources, text expansion, truncation and unsafe concatenation while engineers still hold the relevant code 6. We have covered the mechanics in software localization is not a translation project. Here its value is economic: it measures an option before you buy the market.
A deliberate deferral has an assumption and a trigger
A deliberate deferral needs a record. Not a backlog item called “add i18n”, because that names no decision and has no reason to move. Record the assumption that made the shortcut rational, the surface exposed by it, the cheapest guard worth keeping, the event that reopens the decision and the person who can act when it occurs.
Assumption This product will serve one language for the next 12 months.Exposure Messages, formatting, layout direction, names and addresses.Guard Externalized messages and a pseudolocale smoke test.Trigger A signed customer, a supported-market decision, or 5% qualified demand.Owner The person who can reopen the architecture decision.The trigger cannot be “when localization becomes important”. Importance is what the record is supposed to operationalize. It can be a signed customer, a country entering the roadmap, a share of qualified demand, an applicable document duty, or a planned rewrite that makes the boundary cheap to add.
The guard also has to match the exposure. A pseudolocale can expose hard-coded strings and expansion. It cannot prove that an address model works outside one country. A locale-aware formatter cannot make a fixed-width component flexible. The earlier post on the definition of software localization separates those surfaces because one control cannot stand in for all of them.
The second locale is the messenger, not the debt
The useful roadmap question is not whether another language is needed today. It is which parts of the product have made tomorrow’s yes expensive, and whether today’s priorities are paying enough to accept that debt.
Refusing localization can be a disciplined market decision. Refusing internationalization can be a disciplined architecture decision in a prototype, a retiring module or a genuinely bounded system. The two refusals need separate reasons because they buy different things and become expensive on different schedules.
A wall can stand on one familiar support for years. When the second support requires a deeper excavation, it is tempting to blame the new support. The hole belongs to the ground the first design never had to inspect.
The second locale did not create the debt. It was the first honest test of whether the product had one.
References
- 1.W3C Internationalization Working Group Localization vs. Internationalization W3C Internationalization
- 2.Google Localize your app Android Developers
- 3.Escobar-Velásquez, Osorio-Riaño, Dominguez-Osorio, Arevalo and Linares-Vásquez, 2020 An Empirical Study of i18n Collateral Changes and Bugs in GUIs of Android Apps ICSME 2020
- 4.Zhou and Chen, 2017 Going Global: Internationalizing and Localizing a Legacy Financial System Cutter Business Technology Journal 30(4)
- 5.Becker, Fagerholm, Mohanani and Chatzigeorgiou, 2019 Temporal Discounting in Technical Debt: How Do Software Practitioners Discount the Future? TechDebt 2019, arXiv:1901.07024
- 6.Microsoft Pseudolocalization Microsoft Learn