I deal with the following regularly: when distributing modules, the resource files are normally UTF-8 encoded and this is specified in the declaration. Then people edit stuff and save and send me files and I edit them and save and etc etc. In short: the file passes through numerous systems and accidentally is no longer UTF-8 encoded. This is not noticable to the naked eye as most editors load these text-based files as is, and save them. The main problem, though, is that DNN invariably breaks as dotnet cannot read an xml file that specifies UTF-8 encoding in the declaration and is not really thus encoded. You get a nice unhelpful message saying Object reference not set to an instance of an object. at DotNetNuke.Services.Localization.Localization.LoadResource etc etc. The reason that it can go unnoticed by me, the developer, is that I don't load in all locales for every page before it leaves the lab. I rely on outside sources to deliver the resx files and this sometimes leads to this issue.

Proposal:

1. Make DNN localization a little more robust. It should not bomb out when dotnet can't read the resx file. It should gracefully retreat to our beloved us-EN localization as it would if the resx file wasn't there.

2. A repair tool. This would check all resource files for any anomalies including the one I mentioned and propose fixes.

Whaddaya think?

Peter