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.
Related
Sorry for the noob question.... but
I have a rather large unilingual application that I have to make multilingual, meaning no resource file. I don't have the option of using the culture information but need to do it more on the fly at runtime so that the user can change languages either on startup or menu pick while in the application. I can handle that part ok. I realise there are traditional ways to set these values but I'm hoping to find a better solution.
What I'd like to be able to do is the following
First of all is this even possible? I've taken a pretty good look around and didn't really find anything close to what I'd like to do. I would even be willing create a few user controls if that was the solution. In the end I'll have to do this for buttons, labels, datagrid headers and messages(these are easy lol)
Any thoughts would be appreciated.
Thanks
Yes it is possible. Try this article: Creating an Internationalized Wizard in WPF.
Specifically look at the startup code for the application where CurrentCulture is modified for the CurrentThread.
Do not feel locked out of using per-culture resources by WPF. Different resources can be used via the "PublicResXFileCodeGenerator" as described in the article.
The MSDN Docs - CultureInfo.CurrentCulture Property may help.
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai
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've finnished to read all the topics of WPF and I want to develop an application so I'll be sure I got it.
I want it to include all the topics : binding, converters, UCs , MVVM , templates .. etc.
any ideas ?
Huh. Do you have expertize in some area besides programming? Or at least some knowledge?
For additional inspiration, here's list of ideas YCombinator would fund.
You can easily start Open source model development. Who knows if you understand WPF better you can even create a new framework altogether which will help the WPF community.
If you want to build an application, might be you can go for something like Video Albums etc, which have large capabilities of rich UI elements.
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