Charlie’s Approach to Globalization
In an earlier weblog entry, I noted that once I had a few systems in place, I was a little unsure of what to tackle next in the development of Charlie. A review of my software specifications showed that security and globalization were high priorities and deserved early attention. Having addressed security, my attention turned to globalization.
Just as my stubbornness had a part to play in Charlie’s approach to security, it had a part to play in Charlie’s approach to globalization, too.
As I have attempted to do in all aspects of creating this application, I started by researching the topic. But in reading the prevailing wisdom on the topic of globalization in ASP.NET applications, I often found myself shaking my head thinking, “But that’s just dumb.”
If you research the topic, you’d be forgiven for thinking that globalization is some sort of dark art. The white powers of forethought and traditional programming will not work here. Oh no, you must conjure the black powers of resources files and satellite assemblies.
But first, what is the problem that we need to solve? The problem is that if the website is to be presented in more than one language, it means all words and phrases need to be extracted from the code. Other stuff also needs to be extracted, but let’s not get distracted by details. The words and phrases need to be put ‘somewhere else’ and then ‘brought back in’ when the application is running.
You will see then that the problem of creating a multi-lingual web application breaks down to two smaller problems. First, where is the ‘somewhere else’ that we can store our text? Second, how is that text ‘brought back in’ when the application is running?
Let’s start by looking at the second problem, and how it is solved in .NET. The solution is to create a key-value collection for each supported language. Each collection is known as a resource. At runtime, a ResourceManager is asked to provide the most appropriate text value when handed a key.
To take an example, the application is presenting a webpage to a Canadian French visitor, and it needs to display the word ‘Save’ on a button. The application will ask the ResourceManager for the most appropriate text for the ‘SaveButtonText’ key. The ResourceManager will first check whether there is a resource for that specific Canadian French culture (fr-CA). If so, it will check whether it contains the requested ‘SaveButtonText’ key. If not, the manager will check whether there is a resource for the neutral French culture (fr) and, if so, whether it contains the requested ‘SaveButtonText’ key. If not, the manager will fall back to the default culture resource and check whether it contains the ‘SaveButtonText’ key. If not, an empty string will be returned. (Need I say that if the key is found in a resource, the corresponding string value is returned?)
That is a simple and flexible solution to the second problem, which is how text can be ‘brought back in’ when the application is running.
Let’s now look at the first problem, which is to find ‘somewhere else,’ outside of our code, where we can store our text. For some reason, the prevailing wisdom is that we must create resource files and satellite assemblies. (We can use the resource files without compiling them into satellite assemblies, but that is never shown as the way to do it.) This makes sense for shrink-wrapped software, but makes no sense for ASP.NET applications.
The problem still is that we need ‘somewhere else’ to store our text. May I suggest the database? Do the six letters that spell out “Friend” become suddenly different if they are to be used as an interface element rather than being used as a role name? If we stick this word in a resource file that gets compiled, the website owner cannot change this word without going back to the developer and getting a new satellite assembly. If we instead stick this word in the database, the website owner can change it for herself. Or, her translater can change it for himself. We place all other text in the database—why treat globalized text any differently?
The only apparent reason to use satellite assemblies in an ASP.NET application is because Visual Studio expects us to do it this way. But that means putting the developer of the application first, and the customer of the application second. That is of course very, very wrong.
While the .NET solution to the second problem—how localized text can be ‘brought back in’ to the application—is simple and flexible, the .NET solution to the first problem—finding ‘somewhere else’ to store the localized text—is complex and inflexible. So poor Charlie, whose stubborn master sacrifices everything to the gods of simplicity, had to find a different solution to the first problem.
by Alister Jones | Next up: Separating Chrome and Content →
----
I couldn't agree more :)
Resource files seems stupid to me :P
Although I usually solve the problem of internationalistion with .xml files.
But that's just a personal preference on the matter.
Post a Comment