I was contemplating our strategy on how to localize Voyadores—our ERP product—and I was torn whether I should do a file-based approach or a database approach. Localization is typically file-based but my spider sense is telling me that, in our case, it could spell trouble down the road. Turns out my hunch wasn’t far-fetched. This is a hot topic.

Rick Strahl (An MS MVP) has a great tool kit for managing localization via the DB – offer the ability to update and modify on demand through a controlled environment and does much of the heavy lifting for you.

[…]

Resx Resources are also static – they are after all compiled into an assembly. If you want to make changes to resources you will need to recompile to see those changes. ASP.NET 2.0 introduces Global and Local Resources which can be stored on the server and can be updated dynamically – the ASP.NET compiler can actually compile them at runtime. However, if you use a precompiled Web deployment model the resources still end up being static and cannot be changed at runtime. So once you’re done with compilation the resources are fixed.

This was the deal breaker. I can put up with Resx being XML—XML documents are a pain to deal with—it’s clumsy and becomes unwieldy when the file is too big. However, our app has increasingly demanded flexibility. The ability to add and modify application messages and notifications without re-deploying the app saves us dozens of developer hours. It also offloads tasks from our developer to BAs (Business Analysts).

Lastly, I have a beef with applications unnecessarily pulling data from disparate sources. It creates ambiguity to the framework and confuses the developers. We strongly encourage developers to be mindful when picking persistence strategy of their resources (data, configurations, localizations, application variables, etc.). More on this on a later post.