Internationalization
A major funds transfer company started business in the Netherlands when I lived there. (I won't say which one, but you've certainly heard of them, and there's a good chance you've even got an account with them!) My housemates and I were eager to sign up, but their enthusiasm stopped dead at the page asking for their name, 'exactly as it appears on your bank statement—use only English letters'. They were expats like me, and their bank statements had names like Sträßer and Øglænd.
I've lived on four continents, so I've seen all sorts of problems like this. Sometimes they can be very costly for a software company, such as our competitor when I was developing medical software in Sydney. Their product was more mature than ours, but hospitals consistently chose our product anyhow. One of the main reasons was just because ours supported the Australian DD/MM/YYYY date format, and theirs only supported the U.S. MM/DD/YYYY format. This made the difference between, say, December the 1st and January the 12th rather murky, and nobody wanted to risk accidentally giving a twelve-day-old baby a dose intended for a twelve-month-old.
But internationalization is more than just text. I said this to Applied Biosystems when they wanted an internationalized GUI for their biotech instrument, and pointed out that their dialogs and widgets needed to be coded with flexible dimensions, which can affect layout design. The adjacent image is part of the outcome, the Samples Setup tab I developed. If you click it for the full-size screenshot, you'll find the Chinese text large enough to read, and that doesn't go over the edges of the buttons and tabs. This is often not the case when only English is considered at the design stage, because English is a relatively compact language. If you've used software in another language, you too may have seen truncated or illegible text.
Graphics should also be considered; the meanings of symbols and even colors can vary from locale to locale. An often-cited example is the Greek question mark, ;, which looks like a semicolon.
Even when English is the only required language, internationalization should still be considered. I've already mentioned the consequences of date formats, and this importance can be extended to currency, and especially units of measure. And what about spelling? American English has many unique words and spellings that users in other English-speaking countries are unfamiliar with. Other countries have variations too, such as boulevarde and gaol in Australia. A properly internationalized application considers these variations, and I routinely go the extra mile to make this happen. To see this in action, try setting your browser's language to a different English locale, e.g. Canadian English (en-ca), and observe what happens with words like 'colors' and 'dialogs', and the date at the bottom of each page.
Portfolio
I developed much of the UI for a new instrument at Applied Biosystems, and was in charge of internationalization. Here are a couple more partial screen shots of UI I coded, in Chinese. Click them for full-size versions.
The new GUI I developed for Sarwaja Timur in Malaysia featured easy switching between English and the Malay language; I will add screenshots of this when they become available.