documents to PDF, as well. Watch out for processes that either fail silently when fed non-ASCII data or die at the point where they encounter it.
When it comes to web applications, elements that are updated via AJAX are frequent offenders. Browsers may reinterpret the document based on the charset declared in the Content-Type header of the AJAX response, so you need to ensure not only that the updated elements handle non-ASCII characters correctly but also that nothing else on the page goes awry when the AJAX call fires.
Fourth, if your program handles dates or times, it almost certainly needs to be time-zone aware. Fortunately, most every programming language has either a standard or de facto standard library for dealing with date and time calculations. Thus, this issue usually boils down to advocating for the application to be made time zone aware if it isn't, and making sure that time zones are being used consistently if it is.
Finally, data-checking or filtering algorithms need to handle the widest possible range of inputs. Names in particular are very special things when it comes to data validation. You do someone a great disrespect when you tell him that his name is invalid or unacceptable. Patrick McKenzie's excellent and well-linked “ Falsehoods Programmers Believe About Names ” calls out many of the erroneous assumptions commonly made. Amongst other things, names can contain punctuation (D'Orazio, Mary-Lou), spaces (van Meegeren), or syntactically significant mixed case (McLean or, again, van Meegeren).
Phone numbers and addresses are an interesting problem. Their formatting tends to be fairly country-specific, but despite this, even applications that are primarily targeted at one particular locale frequently need to deal with international addressing. For instance, a testing conference taking place in one country is likely to lose a considerable amount of business if its registration web application cannot handle attendees with out-of-country billing addresses. The testing for this kind of functionality should start during the requirements-gathering and design processes. Together, testers, business stakeholders, and developers need to raise and answer questions like: What kinds of addresses do we need to accept? What is the business cost of not handling international addresses? What kind of validation is acceptable? Is simply accepting free-form text for these fields an option?
I18n is not merely a technical issue, but also a business issue. Again, this is one of the areas that make a strong case for testers being involved in the software specification process from the earliest possible point. When told that the software doesn't need to handle i18n, testers need to be in a position to ask what the risk to the business is and what opportunities will be missed as a result. The cost-to-value ratio may not work out in favor of a full-blown translation effort, but less-sweeping changes, including those above, can still make your software considerably more friendly to users from other countries. Is it really wise to pass up more of the international market than absolutely necessary? The world is a big place, and you do yourself a great disservice if you let your thinking be limited by national borders.