Just stumbled across a nice little check list for checking a website is ready for i18n.
Can do quite a few of these checks automagically using something like Selenium to save you time.
Strings Have all strings been externalized? Have all strings been approved by someone who is a native English speaker? Is there overuse of any abbreviations or acronyms, e.g. ‘App Info’? Is there anywhere that you are concatenating strings together? Punctuation is text too! Are you using any hard-coded punctuation marks (.,!?) these need to be externalized? Have you identified all trademarks, tokens and other ‘special’ elements in your text and communicated to localisation that these shouldn’t be translated? For mobile applications, is your text short enough to fit the potential small screen size of mobile devices? Consider string length expands generally 20% – 30% after translation. Some phrases expand by a lot more than 30%. Abbreviations and acronyms are the worst offenders here. Try to keep resources that shouldn’t be translated separate from those that should. Don’t embed HTML mark up in string resources. Source Files Source files are a standard file format – no need to invent new resource file formats. A standard resource file format will exist for the platform for which you are developing. Source files are UNICODE. You need to be able to generate your localizable file set in one step, it’s ideally handled by the build process. General UI Can input fields accept accented characters? Can input fields accept double byte characters? Is there room for buttons to expand if necessary? Are there any UI elements like check boxes or radio buttons that are placed across the screen? It is better to place these vertically. Try to put labels for controls above the control, rather than beside it. Web Applications Is server set up to send UTF-8 character set? Are all buttons resizable? Are there any mouse-over buttons with text in them? Are other elements on the screen able to expand in size? Are links to help and other user documentation appropriately localized? For HTML based UI, never use absolute positioning. NEVER use HTML tables to achieve layout. Try to avoid using fixed widths with HTML layouts. Don’t use the ‘align’ property to align items left or right. Externalize CSS to a separate file – never use inline CSS. Images Is there text in any image? Are there any images that depict hand, body or facial gestures? e.g, the thumbs up gesture is offensive in some cultures. Are there any icons or images that are very specific to one region? e.g. an American type mailbox indicating an email. SQL Use the nvarchar type to store all text. Can all insert and update statements handle unexpected apostrophes? (O’Sullivan, d’accord for example)? Can all insert and update statements handle accented and double byte characters? For MySql, ensure it was installed with UTF-8 as the default character set. Numbers & Dates Do any parts of your application format numbers using a thousand separator or a decimal point? If so the formatting string must be read from the OS. Do any parts of your application format currencies? If so the formatting string must be read from the OS. Does changing the application locale change all numbers appropriately? Are all time and date formats read from the OS based on locale? Does changing the application locale change all dates appropriately? Regular Expressions Do any regular expressions use the construct [a-zA-Z]? These are not safe from an i18n point of view. Never use a regular expression to find a price, as the currency will be different for different languages. Collation/Sorting Do any parts of your application sort alphabetically? If so then they need to be tested for i18n awareness.