I recently had a conversation with a fellow member of the coding fraternity concerning what would be involved in taking an existing development (C#, WinForms, SQL Server) that currently is an English-only application, and converting it to support multiple languages within a reasonable time-frame/budget.
The conversation centred on specific problem domains to consider and not necessarily how to solve them, although we quickly took a stab at some solutions as well. We jumped around from UI to code to DB and back again, so we decided to make a list. I've posted them here for all to peruse (who knows, maybe you're doing the same and need inspiration). If you feel we've missed something, or possibly overcomplicated an issue, please comment and I'll update the post.
Starting at the bottom:-
The Database
I've found quite often that text fields in tables are not Unicode-compatible. This means that column-type changes need to be made to allow for Unicode characters and that the columns affected will be string types. Another Sql problem that may arise is if you have varchar columns that have a total length close to the 8000 mark, or in fact anything over 4000, as you will get SQL warnings when these tables are recreated. Some data type conversion to look for are:
- varchar to nvarchar
- char to nchar
- text to ntext/nvarchar(max))
- Collation for columns should be changed to database default
If you’re making use of functions and stored procedures, the parameters need to be checked as well.
Another consideration is when your application may be used with on operating systems with different languages all connected to the same SQL server. Lookup tables need to either have a column per language (not a good design idea) or make use of a lookup on the lookup table. A classic case would be the title column in a category table; the lookup needs to be localised for the current language.
Replication, if there is any, needs a close look, especially if the two SQL servers are on different languages.
Code
Any code referencing the file system needs to make use of environment variables for common paths (e.g. temp folder, program files, my documents).
Often, date checking takes place in code, or more than likely, formatting a date to '07 Aug 2007' will happen just before a insertion into SQL. Localised abbreviations vary and may throw a spanner in the works.
If you are logging exceptions to a trace listener (or you're using log4net :)), make sure that you include verbose messages for your own use. You'll most likely be testing your application on an English installation of Windows, with the language changed, and feel that the current system of logging of exception messages is just fine and dandy. This won't be the case, though, on a German installation and you get something along the lines of "Du gemacht einen Fehler."
User Interface
Our first sticking point here was how to support right-to-left languages; we decided that this would more than likely result in a rewrite of the UI layout code, and would most definitely not be part of an "upgrade"
User interface elements that we did think need to be localised included:
- Any graphics that have words included in them
- Field Labels
- Grid headers
- Tool-tip texts (Schneeky, as you don't notice these in design mode)
- Numeric data entry fields, especially with decimal points, need to take the decimal and thousands separator into consideration
- Message boxes and user prompts
- Reporting label fields
All of these need to cater for the chance that the translated text will be longer that the enlgish original.
That was about it for our 20 minute collaboration – I’ll be adding more as I think of it (or someone else does).
Verfluchtes Recht, Hündchen!