In the nearly 11 years I’ve been writing software for real money, I haven’t had any internationalization projects until now. The project I’ve been assigned most recently is an electronic forms application that will allow the spouses of police, fire, and other public safety officers injured or killed on duty to apply for benefits. It certainly isn’t the most cheerful app I’ve ever helped write, but it’s definitely one of the more important ones.
Dealing with resource files has been the biggest pain of the entire project. We lack consistent naming conventions for variable names. We also lack consistent locations for the variable names. This results in the need to pull strings for one form from multiple resource files. Sometimes, variable names and locations have been changed arbitrarily and without warning. This meant that code I’d written one day that displayed the correct text, displayed nothing the next day. A few of those changes cost me half a day of rework (and every bit counts when your deadline won’t move).
When I finally had a chance to look for information on internationalization in .NET, I came across an excellent article at DevX. It’s the first in a 3-part series of articles that ends with a decent checklist of issues to consider in an internationalization project. The sample application is more complex than my assignment because they’re internationalizing database content as well as static content.
So far, I think we would have helped ourselves a lot if we’d thought of the resource files as classes. I’m not sure what the performance implications of more resource files with fewer strings would be versus fewer resource files with more strings, but I think it would improve our speed of development.