Here’s a topic that is not often talked about. What about applications requiring regional configuration for language and styling? Many of us don’t have to worry about working with more than one collation (character set), translations, or difference in data structures unique to a region of the world. B
Currency is a big problem. Conversion rates are continually changing. So, you have to have some mechanism for converting from one currency to another. Moreover, monetary valuation is usually time sensitive. A transaction on Monday may be converted based on the rate of exchange for Monday, not the end of the week, or month.
Address data varies by region. Some countries share a common address scheme, while maybe using different terms for the different address attributes. Other countries have completely different configuration of attributes. You application needs to be able to track the different address attribute configurations.
Language is one of the bigger issues. This is especially true when you support both Latin based languages and Easter languages. Many Latin based languages may be supported with one collation. For example, you may be able to use a single collation for French, Spanish, English and German. Eastern languages, on the other hand, often have a unique collation for a single language.
Language is also impacted by different dialects, varying by country, or even by a dialect within a country. The cover over the front of your car (usually over the engine) is called a hood in the United States of America (USA), while it is called a bonnet in the United Kingdom. In the USA, we have windshield wipers to keep the rain off our windshield, except if you live in Florida, the south eastern most state in the USA. In some parts of Florida, these devices are called Wig Wags.
Telephone numbers vary from one country to the next. Some break the number up into meaningful segments. Others, with fewer numbers. may have a different design. With the continued rise of cell phone use, and the rapidly increasing need for new phone numbers, you can’t be guaranteed that your database will handle future implementations.
Another factor you have to take into consideration is the time zone. While this isn’t strictly a problem supporting multiple regions, since most countries have more than one time zone, we often don’t take time zone into consideration in our internal applications, because time difference isn’t a significant factor in the data we capture. It is more likely that time is relevant when you extend your application to supporting multiple regions.
Addressing these issues requires a lot of work in all tiers of an application to implement correctly. Next week we’ll take a look at some design considerations. My proficiency will be with data structures to capture and store data in a malleable database design. If you’re expertise is in presentation, or handling region specific designs in the user experience, why not consider writing something for SSWUG. Or, simply leave a comment or drop an email to btaylor@sswug.org.
Cheers,
Ben