Shared XAML and localization in Universal Windows apps

This post will show you how to share XAML and localization in Universal Windows 8.1 apps, with a twist. The extra spice in this example is that we have two versions of the app with slightly different branding. A picture says more than 1000 words: (or 38…)


Sharing XAML

There are many different ways of creating branded apps; apps that are basically the same but some color/image/data source differences. What we started with in this iteration was an app on Windows Phone 8 that had one app that is the reference app, and the other apps just link to the files from the reference app (add existing item – add as link). This we wanted to transform into a Universal app environment.

Another way of creating branded apps is to have one single app, but build targets that copies the brand-specific files into the correct location.

Linking files

One problem of sharing XAML by linking files is the magical Shared folder. The Shared folder of Universal apps does file linking behind the scenes, but the Shared folder cannot contain link to other files – there is no add as link when adding files.

To remedy this, we created a PCL targeting Windows 8.1 and Windows Phone 8.1 that will act as our reference app – and all the other apps (both Win and WP) will link to these files.

Here is a picture of the file structure, MainPage.xaml is the shared file.


Sharing resource dictionaries

MainPage.xaml references the AppResources.xaml resource dictionary, which contains the branded assets. (in this demo a background color and app title).

This file exists in the shared master project, but is not linked from there – instead the file is custom in each app project.

Sharing localization

Localization has changed from Windows Phone Silverlight to the Windows XAML model in 8.1. Used to be resx, now resw. An overview of localizing Windows Phone 8.1 can be found here:

Please note, to fully utilize the localization tools available – you want to use the MAT – Multilingual App Toolkit, it’s awesome! I skipped it in this sample, but please refer to this great post on how to use it in universal apps:

So, how did we deal with localization here? Well, almost the same as with XAML. We created a PCL targeting Win81 and Wp81 and created the appropriate file structure:


(The errors.resw files are there just to show how to reference custom-named resources, they are not needed for the main flow of accessing the resources.)

We then added the same folder structure in each of the apps, and then linked the resources.resw files into each app.

The LocalizedStrings file was also linked, and looks like this:

public class LocalizedStrings
  public static string Get(string key)    
    return ResourceLoader.GetForCurrentView().GetString(key);     

Alright! Localization files in one place, and linked once-and-for-all into each of the apps.

Localization in XAML

This XAML:

  Content="design time content"
  Click="ButtonBase1_OnClick" />

Will automatically use the resources defined:


Localization in code

Here we will use the LocalizedStrings class:

private async void ButtonBase1_OnClick(object sender, RoutedEventArgs e)
  await new MessageDialog(LocalizedStrings.Get("ClickMessageText")).ShowAsync();

Accessing resources in other lib & non-standard-named file

If you want to skip the linking of all the resource files, you can access the PCL lib directly by a different syntax, you have to define both lib name and resource file name, like this:


  Content="design time non-linked content" 


private async void ButtonBase2_OnClick(object sender, RoutedEventArgs e)
  var loader = ResourceLoader.GetForCurrentView("/UniversalLocalizationTest.Resources/errors");
  await new MessageDialog(loader.GetString("NonLinkedMessage")).ShowAsync();




With click on first button:


With click on second button:



To change language on Windows, you search for ‘region and language settings’, then change the primary language.


Left out

I left the MAT – Multilingual App Toolkit out of scope for today, you definitely should check it out.


In Visual Studio 2015 there will be support for stand-alone Shared project, that will make this whole linking easier and with less manual linking.

You can try the preview of VS2015 by downloading it from


Microsoft Virtual Academy of course has great contents on developing apps.

Resources (Quickstart: Using string resources (XAML) (Application resources and localization sample)




Thanks for reading! Comments are welcome.

This Post Has 8 Comments

    1. Andreas Hammar

      Beautiful Cristovado!
      Thanks for sharing

  1. Pierre Christophe

    I develop an Universal app that must be “rebrandable”: there will be a “generic” version and “rebranded” versions for customers which request.
    For each version, we want define a name, assets (icon, splashscreen, …) and specific colors.
    Do we only need to change the manifest file? Or should we go through an approach like yours?

    1. Andreas Hammar

      Hi Pierre,

      Tough call, I’ve done both.

      If you go for the “single-app” solution, you could have a separate manifest for each app in a directory somewhere, and a build action that overwrites the main manifest depending on solution config (eg DebugBRAND1, DebugBRAND2).
      It could also copy images, logos, string etc.

      This works fairly well, and is probably suited for a case where you have many apps with different branding. If you know that you only ever will have two/three apps, and/or have a lot that changes between the apps – maybe even a special page or something – the approach above is probably to prefer.

      How much will be custom?

      1. Pierre Christophe

        Hi Andreas,
        I come back to you after having finished the development of the application. This is a classical “Universal App” solution thus containing 3 projects: Windows, Windows Phone and Shared.
        I’m not sure to understand the solution that you have suggested:
        – must I create a seperate manifest in directories of my Windows/Windows Phone projects?
        – how can I so specify the manifest that must be compiled?

        For this app, I have a default version, and 3 customized versions for specific clients.
        Each version must have its own name, icons, background (that are defined in manifest), and custom colors that are defined in a “style.xaml” file. I hope that it is possible to select this specific file through “” of the “App.xaml” file, but I don’t know if it’s possible.

        1. Pierre Christophe

          A text block was removed from my reply:
          => I hope that it is possible to select this specific file through the MergedDictionaries of the “App.xaml” file, but I don’t know if it’s possible.

  2. Isbah

    hi Andreas Hammar,

    I have a hyperlinkbutton , when its clicked it has to convert the default culture to the culture i define. I have used this code to convert it:

    var culture = new CultureInfo(“ar-SA”);
    Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = culture.Name;
    CultureInfo.DefaultThreadCurrentCulture = culture;
    CultureInfo.DefaultThreadCurrentUICulture = culture;
    (Window.Current.Content as Frame).FlowDirection =Windows.UI.Xaml.FlowDirection.RightToLeft;
    var loader = new Windows.ApplicationModel.Resources.ResourceLoader();

    if (Frame != null)

    Problem is, after navigating back to the same page; where i have clicked button. direction is changed from left to right , but old resource file is cached. Any idea how to remove this cache file

    1. Andreas Hammar

      Hi Isbah,
      Sorry but I’m no expert on localization so I might not be able to answer. I’m assuming you’ve cached the page with NavigationCacheMode=Cached/Required? Maybe you can re-apply the culture-stuff in OnNavigatedTo if that is the only part of the page that is not cached?
      So the culture is just applied on this particular page after this button is clicked?
      Is the culture change permanent? Perhaps easier to have a separate page where the culture is always defined?

Leave a Reply