Localising (or localizing) a Windows Phone application is straightforward, however, testing that you have correctly localised the text is harder. One method is to use a pseudo language but I found that has a couple of problems; you need to overwrite a locale (although you can use my previous posts to create a new ‘unsupported’ language), you need to maintain that language with your default language, and…I just find it over noisy. So I present an alternative.

 

Here is an example of an application I am working on;

If I switch on the ‘test localisation’ then the page looks like;

Argh, I’ve not localised ‘save’! The idea is that all the localised strings show up as their resource name surrounded by a ‘%’. I think this makes it easier to spot the non-localised text, plus you could turn it on during a test session therefore allowing you to report the resource id that is incorrectly localised for a specific language.

The code is based on a previous post but I’ll show the code again with the slight adjustments;

Note, if you want to dynamically support switching between a language and testing it, then you need to change the GetString to call the base class

public class TestResourceManager : ResourceManager
{
    public TestResourceManager()
        : base("MyApp.Localisation.StringLibrary", typeof(StringLibrary).Assembly)
    {
    }

    public override string GetString(string name, System.Globalization.CultureInfo culture)
    {
        return "%" + name + "%";
    }
}

Then add a constructor to the default string library.

    public class LocalisedStrings
    {
        private static readonly StringLibrary _localizedResources = new StringLibrary();

#if DEBUG_LOCALE
        static LocalisedStrings()
       {
           Type type = _localizedResources.GetType();
           FieldInfo info = type.GetField("resourceMan", BindingFlags.NonPublic | BindingFlags.Static);
           info.SetValue(null, new TestResourceManager());
       }
#endif

        public StringLibrary LocalizedResources { get { return _localizedResources; } }
    }

After a recent post about how to allow the Resource Manager to use a non-supported culture I wondered how difficult it would be to support the usual  localisation binding. So, in the great tradition of computer science I wanted to bind to Klingon. Whilst I can see that the correct solution would involve writing a custom tool I wanted a quick ‘hack’ and this is what I’m presenting here. To keep the post size down, I’m assuming you’ve followed the previous project and have that project available.

1. Create the Klingon resx. Copy AppResource.en-GB.resx over to AppResources.klingon.resx
2. Add the custom tool PublicResXFileCodeGenerator to AppResources.klingon.resx (see the properties of the file)
3. Write some klingon – open the resx and change the ApplicationTitle to the following Klingon (it’s not rude) – TLHO’
4. Create a new String Library class;

 public class AlienLocalizedStrings
    {
        private static AppResources_klingon _localizedResources; 
        static AlienLocalizedStrings()
        {
            _localizedResources =  new AppResources_klingon();
            Type type = _localizedResources.GetType();
            FieldInfo info = type.GetField("resourceMan", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.SetField);
            info.SetValue(null, new AlienResourceManager("klingon"));
        }
        public AppResources_klingon LocalizedResources { get { return _localizedResources; } }
    }

5. Add the resource to App.xaml

    <Application.Resources>
        <local:LocalizedStrings  x:Key="LocalizedStrings"/>
        <local:AlienLocalizedStrings x:Key="AlienLocalizedStrings"/>
    </Application.Resources>

6. Now you can bind to Klingon, e.g.

 <TextBlock Text="{Binding Path=LocalizedResources.ApplicationTitle , Source={StaticResource AlienLocalizedStrings}}" Style="{StaticResource PhoneTextNormalStyle}" Margin="12,0"/>

The solution works pretty well, obviously the string component is hardcoded to ‘klingon’ which isn’t ideal but I’m sure that can also be resolved with a little more effort. Enjoy Klingon on the phone