Internationalisation is usually scoped as a translation project: extract the strings, send them out, put them back. That part is the most visible and the least likely to cause defects. The failures come from assumptions baked into the data model and the interface - about what a name looks like, how an address is structured, how numbers are written, and how plurals work.
Names are the first casualty. First name and last name is an assumption, not a fact: many people have one name, many have several family names, ordering varies, and in much of India a name may include an initial that expands to a village or a father's name. A single full name field, stored as the person entered it, is correct far more often than a structured split, and prevents the class of bug where a form refuses a legitimate name.
Addresses are worse, because the structure genuinely differs by country. Postcode formats vary and some countries have none. The concept of state or province does not exist everywhere. Ordering differs - the Indian convention of building, street, area, city, pincode is not the American one. A schema with fixed fields for street, city, state and zip will mangle addresses from most of the world; a flexible set of address lines plus a country code will not.
Numbers and dates carry assumptions that produce silently wrong values rather than obvious errors. Decimal separators differ - 1.234 is one thing in one locale and a thousand times that in another. India groups digits differently from most of the world, with lakhs and crores. Date formats are genuinely ambiguous: 03/04/2026 is two different days depending on the reader. Use the platform's locale-aware formatting rather than string manipulation, and store canonical values in the database.
Plurals are the part developers underestimate. English has two forms and most codebases assume that. Other languages have three, four or six, with rules that depend on the number in ways no if-statement will approximate. Use a proper message format that expresses plural categories, and never build sentences by concatenating fragments - the fragments assume an English word order that does not survive translation.
Then the interface itself. Translated text is frequently thirty per cent longer than English, so fixed-width buttons and single-line labels break. Some languages read right to left, which means layout must mirror rather than merely reverse text. And any text baked into an image cannot be translated at all. None of this is expensive to accommodate while building, and all of it is expensive to retrofit - which is the argument for making these choices before you have a second locale rather than after.
