When starting the current version I decided to move the 5 fields we had localized in our web.config to a Resource file (I mostly used Tim Heuer blog post “Silverlight and localizing string data”). I thought I was doing the right thing but I didn’t consider our application and the limitation of Resx resources in Silverlight (I thought it might be used like ResourceDictionary by zipping/unzipping the XAP file). When the problem was discover it was already to late from 5 fields we have grown to use ~40 fields and had plans to expand on that.
So what is the problem? In our application we have a Silverlight web server per country, our deployment process is also a bit different, we always deploy to Israel first (give the application a month or two for the Israeli crowd to find all the bugs) and then deploy it in other countries. Even more difficult is the fact that countries are added on the fly and without any compilation to our application (and they always have little changes in the strings localization department). Whereas changes to Resx files in Silverlight cannot be done without compilation. Because of all of that using the String Resources of Silverlight is not a good solution for our string localization deal.
...
...
private void SaveSilverlightResourcesSettings(StringBuilder parameters)
{
var culture = ConfigurationManager.AppSettings["Culture"] ?? Thread.CurrentThread.CurrentCulture.Name;
var filename = Server.MapPath(String.Format("Resources\\StringsResource.{0}.resx", culture));
if (!File.Exists(filename))
filename = Server.MapPath("Resources\\StringsResource.resx");
TextReader tr = new StreamReader(filename);
parameters.Append(StringsResourceName.Name);
parameters.Append("=");
parameters.Append(HttpUtility.UrlEncode(tr.ReadToEnd()));
parameters.Append(",");
tr.Close();
}
line 3: the current culture is taken from either the web.config or the server value (allowing multiple culture web sites in the same server)
Line 4: takes the file by the culture set in the server (that allows us to save the resources string in the Source control if we have them at development time). If it doesn’t exist we take the default file.
Read more: Dll Shepherd.Net