The steps for localizing Silverlight applications using standard .resx files are relatively straight forwards. You can follow these steps on my "Internationalizing Silverlight" slides and see a completed demo in the downloadable source code for the same presentation (see the Localization101 folder). The main problem to resolve in this scenario is that the strongly typed resource class must be public and must have a public constructor. The solution to this problem lies in a previous blog post. This blog post discusses the next stage.

Silverlight faces the same deployment problem that ClickOnce applications face: if you follow the regular localization route then your deployment solution includes all languages for all users. Purely for performance reasons this is not desirable. The optimum solution is to provide the user with only the resources for the one required language. There is no built-in solution in Visual Studio 2010 that covers this scenario - that is what this blog post is about.

The solution is to build one XAP file with the Silverlight application and fallback resources (e.g. SilverlightApplication1.xap) and a separate XAP containing language-specific satellite resource assemblies for each deployed culture (e.g. SilverlightApplication1.fr-FR.xap, SilverlightApplication.es-ES.xap). At runtime the Silverlight application dynamically loads the required XAP resource file. In earlier versions of Silverlight this was possible using WebClient to download the XAP file and AssemblyPart.Load to load the satellite resource assembly into the Silverlight application's domain. This is still possible but MEF (Managed Extensibility Framework) provides a much neater solution (MEF, however, performs almost exactly the same steps as the original solution). To load and use the XAP resource file change the App.Application_Startup event in App.xaml.cs to:-

private void Application_Startup(object sender, StartupEventArgs e)
{
    string xapResourceFilename = String.Format("{0}.{1}.xap",
        "SilverlightApplication1",
        Thread.CurrentThread.CurrentUICulture.Name);

    DeploymentCatalog catalog = new DeploymentCatalog(
        new Uri(xapResourceFilename, UriKind.Relative));

    CompositionHost.Initialize(catalog);

    catalog.DownloadCompleted += (s, args) =>
    {
        this.RootVisual = new MainPage();
    };

    catalog.DownloadAsync();
}

This code uses MEF's DeploymentCatalog to load the XAP resource file (e.g. SilverlightApplication1.fr-FR.xap) containing the application's satellite resource assembly (e.g. SilverlightApplication1.resources.dll). The new MainPage is only created once the download is complete (or has failed). At this point the satellite resource assembly has been loaded into the Silverlight application's app domain and the regular ResourceManager (or whatever resource manager class you use) can get to work resolving the resources. You can see a completed demo in the downloadable source code (see the DownloadOnDemand folder).

The hardest part to solve in this process is the creation of the XAP resource files (e.g. SilverlightApplication1.fr-FR.dll). There is no support for this scenario in Visual Studio 2010 so you have to build this bit yourself. Or rather, you have to download the MSBuild tasks that I have created to solve this problem. Silverlight.Build.Tasks.zip contains the source code to build a library of MSBuild tasks (Silverlight.Build.Tasks.dll) and an MSBuild targets file (Silverlight.Build.Tasks.targets) that you add to your Silverlight application's .csproj file. Full details are in the solution's ReadMe.txt but in essence you add the following lines to the bottom of your .csproj file:-

<Import Project="$(ProgramFiles)\MSBuild\I18N\Silverlight\v4.0\Silverlight.Build.Tasks.targets" />

<Target Name="AfterBuild" DependsOnTargets="XapResourcePackager">
</Target>

Then you add the following line immediately below your .csproj's </SupportedCultures> line:-

<PackageCultures>fr-FR</PackageCultures>

(where <PackageCultures> contains a comma delimited list of cultures to create XAP resource files for).

The result is that when you build your Silverlight application the necessary XAP resource files are also built. If your Silverlight application has a corresponding website that hosts the Silverlight application then those XAP files are copied to the website's ClientBin folder just like the Silverlight application's XAP. You can see a completed demo in the downloadable source code (see the DownloadOnDemandAutomatedBuild folder).

Of course this only covers one Silverlight deployment scenario but it is common enough that it demands a solution.

Enjoy.