We bind ours through the ViewModel into a resx.
We have a modular app, so we split our resources into Common (external DLL) and
Module Specific (same DLL as View/VM).
So in our VM, we'd have something like this :
#region Resource Strings
public object Strings
{
get { return _strings; }
}
private readonly ResourceStrings _strings = new ResourceStrings();
public object CommonStrings
{
get { return _commonStrings; }
}
private readonly ResourceCommonStrings _commonStrings =
CommonStringFactory.GetResourceCommonStrings();
#endregion //Resource Strings
The XAML in the View would then bind like this (assuming DataContext is the VM)
:
<Button Content="{Binding Path=CommonStrings.V_Ok, Mode=OneTime}">
Or
<Button Content="{Binding Path=Strings.V_AddOrder, Mode=OneTime}">
I mention the Common ones explicitly because there's an annoying bug from
VS2008 which still seems present in VS2010 whereby the constructor of the
resources class keeps being set to an internal method every change rather than
being a public method. It's referenced in MSConnect as a bug to be addressed
but I can't find the URL offhand.
So we have to wrap access to a common app-wide set of resources with a factory :
/// <summary>
/// Factory to create an instance of <see cref="ResourceCommonStrings"/>.
/// This is required because a Visual Studio 2008 bug sets the constructor of
/// that class to be internal rather than public, so this is needed to allow
/// other assemblies to access this resource assembly
/// </summary>
public static class CommonStringFactory
{
static ResourceCommonStrings _instance = new ResourceCommonStrings();
/// <summary>
/// Gets an instance of ResourceCommonStrings
/// </summary>
/// <returns>new instance</returns>
public static ResourceCommonStrings GetResourceCommonStrings()
{
return _instance;
}
}
Have been using this approach for a couple of years now with something in the
region of 4000 localised strings. Splitting it out into a single Common resx
and a resx per module (ie block of function) helps keep it manageable in the
resource editor. The largest single resx I can see on a quick code scan looks
to be about 300 strings or so, so there may be issues if you went for a single
huge one which we haven't encountered.
Not saying this is the best option - just the one we settled down and lived
with after a brief period of experimentation.
Martin
Martin Crimes
Clarity Retail Systems Limited
www.claritycommerce.com<http://www.claritycommerce.com/>
From: [email protected] [mailto:[email protected]] On
Behalf Of Greg Keogh
Sent: 29 October 2010 04:38
To: 'ozWPF'
Subject: WPF Localization
I'm in a different part of the coding now. I'm looking of best practices in
localise a WPF application. There are lots of articles around that discuss
using locbaml or resx files and binding. The locbaml approach looks tedious and
I won't consider it unless someone has something nice to say on its behalf.
Using resources generated from resx files is more familiar to me. I wrote a
little test IValueConverter that acted as both source and converter, it works,
but the XAML to call it is ridiculous and would bloat the XAML terribly.
<app:AppResourceConverter x:Key="rescon"/>
...
Content="{Binding Path=Lookup,Source={StaticResource rescon}, Mode=OneWay,
Converter={StaticResource rescon}, ConverterParameter='FooKey'}"
So I set the resx generated class to be public and use XAML like this:
xmlns:app="clr-namespace:MyCompany.MyApp"
...
Content="{x:Static app:AppResources.StringFooKey}"
Now this looks much crisper and readable, but I have to set the resx tool
generated class to public and the class will grow to have huge numbers of
public properties as the number of strings .
Has anyone else had to localise a significant WPF application in anger? Are
there other tricks I haven't thought of that make the process easier?
I see Rick Strahl has written a markup extension (wpflocalization.codeplex.com)
which looks hopeful and I'm reading about now.
Greg
Clarity Retail Systems Limited, Paterson House, Hatch Warren Farm, Hatch Warren
Lane, Hatch Warren, Basingstoke,
Hants, RG22 4RA, UK - Company Registration No: 02739937 - Registered in England
The contents of this email are intended for the named addressee(s) only. It
contains information which may be confidential and which may also be
privileged. If you are not the intended recipient(s) please note that any form
of disclosure, distribution, copying or use of this communication or the
information in it or in any attachments is strictly prohibited and may be
unlawful. If you have received it in error please notify the sender immediately
by return email or by calling +44(0)1256 365150 and ask for the sender. Where
the content of this email is personal or otherwise unconnected with Clarity
Retail Systems Limited or our clients' business, Clarity Retail Systems Limited
accepts no responsibility or liability for such content. It is your
responsibility to verify that this email and any attachments are free of
viruses, as we can take no responsibility for any computer viruses.
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
