Most teams discover software localization the same way: three weeks before a launch, when somebody notices the German button text is spilling out of its container and the date on the invoice screen says 03/04 without anyone being sure whether that means March or April. By then the cheap fixes are gone. The work that would have taken a fortnight if it had been planned takes two months and a rewrite of the settings screen.
What Software Localization Actually Covers
Translation is the visible part and the smallest part. Software localization is the process of adapting an entire product, interface text, layout, formats, images, legal notices, payment flows, keyboard behaviour and support content, so that it feels native to a user in another market. A product can be perfectly translated and still be unusable if the address form insists on a postcode in a country that does not have them.
Internationalisation Comes First
Nothing sensible can happen until the code is ready to hold more than one language. Engineers call this step internationalisation, and it means separating every user facing string out of the source, adopting Unicode throughout, using locale aware libraries for dates and numbers, and making sure the layout can survive text of a different length or direction.
Skipping this is the single most expensive mistake in the field. Strings hardcoded into components have to be hunted down one at a time, usually by someone who did not write them.
Strings Are Not Sentences
Developers habitually build messages by joining fragments together. It works in English and collapses everywhere else, because word order, gender agreement and pluralisation all move. A string that reads "You have" plus a number plus "new messages" cannot be translated correctly into Polish or Arabic, which have more plural categories than English does, or into languages where the verb has to agree with something the fragment does not know about.
The fix is unglamorous. Pass whole sentences with named placeholders, supply plural forms properly, and give translators a comment explaining the context. A translator looking at the word "Open" with no context cannot tell whether it is a verb on a button or an adjective describing a ticket.
Text Expansion and the Layout Problem
English is compact. German, Finnish and Russian routinely run 30 per cent longer, and short interface labels can double. Chinese and Japanese usually run shorter but need more vertical space for legible character rendering. Fixed width buttons and single line labels will break, and they break in the languages nobody on the team can read.
Test Before You Translate
The cheapest way to find these faults is pseudolocalization, which replaces every translatable string with a padded, accented version of itself. Run the app in that mode and anything that stays in plain English is a hardcoded string, anything that overflows will overflow in German, and anything that renders as boxes has an encoding problem. All of it surfaces before a single word has been paid for.
Formats, Names and Addresses
Date order, decimal separators, thousands separators, currency position, first day of the week, measurement units, telephone formats and address structure all vary. So do names. Plenty of systems still assume a first name and a last name, which fails for people who use one name, for cultures that put the family name first, and for anyone with multiple surnames. These are not edge cases in the markets where they are the norm.
App Store Metadata Is Part of the Product
Store listings, screenshots, keywords and release notes drive discovery, and they are frequently left in English long after the interface has been localised. Teams that treat listing copy as marketing material rather than product content usually find their translated app invisible in local search. Specialist app localization services handle both together for exactly this reason.
Games Are the Hard Case
Game localization adds constraints that business software rarely faces. Subtitles have reading speed limits, voice lines have to fit lip movement or at least timing, humour and wordplay need rewriting rather than translating, and rating boards in different countries have different views on content. It is closer to adaptation than to translation, and it is priced accordingly.
Continuous, Not Big Bang
Software ships weekly now, so a localization process built around a quarterly handover cannot keep up. Modern teams push new strings to their translation platform automatically as part of the build, review them in context, and pull the finished translations back before release. The alternative is a permanent gap where new features exist only in English, which is precisely the experience that teaches users to switch the language back.
What to Ask a Supplier
Ask how they handle context, whether translators see screenshots or a live preview, how terminology is maintained across releases, what happens to a string when the English source changes slightly, and who performs linguistic testing on the built product rather than on a spreadsheet. Ask for a glossary and a style guide as deliverables, not as favours.
The cost of getting it wrong is rarely a mistranslated word. It is a market that never takes off, and the reasons for that only become obvious afterwards, as the long history of global brands that skipped proper localization keeps demonstrating.
