How many times have you gone through this scenario? You start out a project, and you ask all the right questions including:
Will this application ever need to support multiple languages?More often than not, this answer will be "No, that's crazy. Don't add support for that. It will take way too much time".
Now fast forward months / years into that project. How many times do you find out (usually in a conference call) that some huge customer in Elbonia that wants to buy a bazillion licenses of your software, but only if it's localized in Swahili.
This is the part of the story where the developers usually try to explain how difficult such an endeavor would be and that the next planned release will be postponed by orders of magnitude.
As in most cases, an ounce of prevention is worth more than a pound of cure. The only way to avoid this miserable situation is to build in internationalization support from the beginning. There are numerous objections to supporting this from the beginning:
- It will take too much time to add support for multiple languages
- It's too burdensome to add new strings
- Working with the UI is too much of a pain
- All of the strings are in one place, so it's easy to maintain phrasing style for the whole project even with multiple developers.
- Common strings can be reused (e.g. Cancel, OK, Username, etc). If a decision is made to change one of those, it gets changed everywhere.
- Testers can usually make changes to spelling, phrasing, etc without bothering the developers. I've spent way too much time correcting spelling, phrasing errors when a tester could have just done it themselves if they had ready access to the strings.