What would be a good aproach to localize a MVVM based WPF allication that can change its language at runtime? Of course I could create a string property in the ViewModel for each and every string that is displayed somewhere in the View but that seems rather tedious to me. Is there a common approach/best practice for this?
Here's an excellent article about WPF localization. It deals with the Microsoft-supported localization technique, and a few alternative ones
I wouldn't recommend the "official" solution for localization... it's really a pain to use, it modifies you XAML (adds x:Uid attributes to every element that can be localized), and there are no good tools from MS to make it an easy solution. Good old resx localization is much easier to use, and integrates quite well with WPF with just a few tricks (namely, markup extensions and/or attached properties). Also, you can easily change the interface language at runtime thanks to the binding system.
WPF has a lot of support for localization. Perhaps you can leverage that? Unfortunately I think that changing the user interface language at run-time is somewhat difficult and you probably need to come up with your own scheme.
Also, as the view-model is UI agnostic I don't think storing user interface strings in the view-model is a good solution. These belong to the view.
Instead of having user interface strings in your view model, you can store them in the assembly's resources and access them directly from XAML, using x:Static:
<TextBlock Text="{x:Static props:Resources.MyLabel}"/>
The props namespace should refer to your assembly's Properties namespace:
xmlns:props="clr-namespace:My.Assembly.Properties"
You can use a Custom Markup Extension to lookup localized values and update them when the UI Culture changes.
Here's an example of how this might work:
<Label x:Name="lblResxHelloWorldMarkupExtension1Value"
Content="{res:Res Id=HelloWorld,Default=Hello#}"
Margin="{res:Res Id=HelloWorldMargin,Default=10}"
Width="{res:Res Id=HelloWorldWidth,
ResourceSet=WpfClickOnce.MyFormRes, Default=50}" />
This example is taken from the excellent WPF Localization Guidance authored by Rick Strahl and Michele Leroux Bustamante here: http://wpflocalization.codeplex.com/. Download the guide from this site where this technique is described in detail in document form and with a sample application.
Another nice advantage of this approach is that it works in the designer.
If you are almost interested on this topic you can have a look at my library that I'm developing on codeplex.
LocalizationLibrary: http://localizationlibrary.codeplex.com/
Here's a couple of articles that could be of interest:
Localizing WPF Applications using Locbaml
WPF Runtime Localization
Simple WPF Localization
Related
I am planning to learn XAML. I wanted to know if I should first learn about WPF and then start XAML?
Please advice.
It depends on what your future plans are with XAML/WPF. If you want to get up and running and use it as quick as possible you might consider starting with XAML and WPF at the same time (but note that you can't learn or use WPF just be learning about XAML).
If you plan to work with XAML/WPF for a long time and you will have a lot of WPF projects ahead you probably should consider starting with "pure" WPF.
I belong to the latter camp and it helped me a lot to first get to know the WPF object model, rendering and layout system and then start with XAML, styles, templates etc. For me it made thinks easier to understand (and there is a lot to understand). I understood that XAML is just another way to represent/serialize a .NET object graph that is built as a layer on top.
This is also the way Charles Petzold's book is structured and I think it is the perfect book to start with when you want to get to know WPF really well.
Its not a good question but WPF applications are is built on XAML. I started learning from WPFTUTORIAL
You will find that you will are likely to learn both at the same time. That said, XAML is a designed to be a mark-up language and is used for several technologies, e.g. WPF and WCF et. al.
As #bitbonk mentions, several books on the subject first give you an introduction to WPF (Dependency Objects, Visual Tree and Logical Tree, Controls, etc) before showing any XAML markup.
Whatever you do make sure that your first 2 or 3 applications are throw away apps (not production code). I have seen way too many developers code themselves into a hole when learning to code with WPF. I would recommend studying the MVVM pattern as well. This is critical to building stable WPF applications.
Here are some blog posts I have written that may be of some assistance.
http://tsells.wordpress.com/category/mvvm/
As far as I know, XAML is only used in WPF and Silverlight, isn't it?
Thanks.
No, it is also used in Windows Workflow Foundation:
Using Workflow Markup
XAML is also the basis for XPS.
It is also used in Office 2007+ *x formats
You can use it for whatever you like (beginning with .NET 4.0 if I'm not mistaken, didn't try it in 3.5).
However, if you do so, please also use the other good things .NET has to offer, such as "INotifyPropertyChanged" and dependency properties. Otherwise whatever you create will be a less - than - optimal solution.
There is a huge mistake I often see people make when they say, "XAML is UI markup." It's not. You can have XAML with no UI whatsoever. XAML is, in essence, an XML object graph. It is markup for creating classes. It provides the parser with instructions on how to generate instances of types and set properties on those types. This is extremely useful for creating UI in WPF and Silverlight but can also extend to sample data, view models, and other constructs. As mentioned here, it is also used in Workflow and other areas.
I came through this What is the best way to localize a WPF application, sans LocBAML? . But, this didn't answer what I'm looking for.
I'm creating a CustomControl in WPF. I would like to provide localization support. The control contains, images, strings etc.,
Any help would be greatly appreciated.
Thanks
I think the document linked in this post contains a lot of information about localization in WPF. In the end, it is up to you to decide which mechanism to use.
Since you are talking about a custom control, I would consider to give it a Culture dependency property which the consumer of your control can use to specify the desired culture. This way, the consumer can use your localized control, relatively independent of the localization strategy he/she chose.
I'd suggest using Resx, try integrating into a WPF application with the TranslationByMarkupExtension example. http://www.wpftutorial.net/LocalizeMarkupExtension.html
LocBaml was a very odd thing for Microsoft to put out there and isn't better, or even complete.
Back in January 2009, Dino Esposito published an article on MSDN titled "Managing Dynamic Content Delivery In Silverlight". We are considering using an approach like this for an upcoming project and were wondering if anyone had any advice on whether this is a good approach. Are there any traps or pitfalls we should look out for? We currently use Prism and would need to look at how the two would live happily together.
Yes! This approach, in my opinion, is what makes Silverlight and WPF so incredibly powerful. I have done this in the past and it is AMAZING how well it works. Data binding and ViewModels make it especially easy to do. Even better is if you use the dynamic capabilities of C# 4.0 to push dynamic properties into your ViewModel that your View can bind to. In other words, you can push down dynamic values that your dynamic views can bind to.
When you get it all working, it is beautiful.
A bit of self promotion here, but my ViewModel base class has a lot of support for this type of dynamic data binding approach.
As far as doing this with Prism, you can take advantage of the modularity Prism that prisim was built with. You can override the RegionRegistry, for example, with one of your own that knows how to create the dynamic view given the region name.
Beautiful, Beautiful stuff here.
I've been very happily using the Model-View-ViewModel (MVVM) pattern in WPF and Silverlight apps in combination with C#. Declarative XAML markup and data binding are invaluable - I just can't live without them. But, this talk by Harry Pierson on dynamic languages got me excited about learning a dynamic language, and I'd like to try one out in a new project. I've been enjoying reading IronPython In Action, and it does contain a few WPF examples - but only with imperative-style code.
What are your thoughts on using IronPython or IronRuby at the ViewModel and Model layers in MVVM apps (compared to C#)? Which features of make them attractive (or unattractive)? I'm interested in fundamental advantages/limitations (e.g. AOP, duck typing, monkey patching, static type limitations, etc) and practical ones alike (e.g. performance, no current IronPython Studio for v2, etc). Will any limitations improve with C# 4.0?
Thanks,
David
Shay is right, but only for Silverlight and I've not used Silverlight and IronRuby. You can bind and use commands with pure IronRuby and WPF. I'm assuming this also applies to IronPython as they both use ICustomTypeDescriptor. there is a caveat, you'll need a DLR build more recent than IronRuby 0.9 for events.
To create an IronRuby command, you need to implement events. See this SO question for more Implementing and Interface in IronRuby that includes CLR Events
As for creating an IronRuby object that can participate in binding, the deal is a an attr reader/writer needs to be used for the DLR to see it as a property.
class Bindable
attr :some_property, true
end
I've got a few Gists about it. A Command Example, A simple ViewModel Example with Binding And the XML Builder based xaml library used in the examples. These worked for me.
There are limitations. XamlLoader can't see IronRuby classes from the CLR. This means your views are REALLY dumb (zero code-behind), or they come from a C# dll. It also means that you can't create custom or user controls that have any code behind without going to C#.
While I don't have a fully baked MVVM app in IronRuby/WPF, I think all the pieces are in place and I'm getting there.
I can say that writing WPF with IronRuby is pretty cool, and if you invest a little time metaprogramming your environment, it can be awesome.
However, there are the downsides - data binding doesn't work with IronRuby objects (you must use CLR objects for that - look at my blog post for the workaround), but this should improve on .Net 4.
Pay attention that IronRuby is expected to go RTM only in November.
Having said all that, I do recommend you check it out. You might fall for it like I have :)
Shay.
I've blogged about my experiences trying out IronPython and MVVM with WPF here. It was surprisingly easy to get going.