From the outset of our project we've been storing strings in a resource file 'MyResources.resx', which was done to support the possibility of localizing the software in the future.
We've been using the following syntax for referencing the strings:
<TextBlock Text="{x:Static MyResources.Hello}" />
Is that correct, or should we be using the following:
<TextBlock Text="{Binding Source={x:Static MyResources.Hello}}" />
I've only recently come across the second syntax so I'm a bit concerned that what we've been using wouldn't actually change the text at runtime!
Also, is it okay to have the resx file in the main project, or should it reside in a project of its own? From the little I've seen about the localization process, it seems to involve generating a new DLL - is this a "full build" of the whole project, or does it (somehow) just extract the translated resx file(s) into the DLL?
For static localization, where you do not need to dynamically switch languages at runtime, your first example is the most straightforward solution. x:Static has relatively little overhead. It's nice and lightweight.
The second syntax won't make a difference in your case: the resource properties you are binding to do not raise change notifications, so the UI would not reflect any changes if you change MyResources.Culture at runtime. In either case, only newly created UI elements would reflect the new language.
If you do need to switch languages dynamically, neither of these approaches will suffice. There are some resources out there that can help you, but if you can get by with what you have, it'll make your life a lot easier. There's also a middle ground: you could create a custom MarkupExtension that takes in a text resource ID and provides localized text. Initially, it could simply delve into your resx resources, but you could potentially refactor it into a more dynamic solution later on (if and when you decide you need it).
From the little I've seen about the localization process, it seems to involve generating a new DLL - is this a "full build" of the whole project, or does it (somehow) just extract the translated resx file(s) into the DLL?
I believe what you're referring to is a satellite assembly. As I recall, satellite assemblies contain localized resources for a specific culture, but nothing more. You would bundle them with your main application or library, and the resource infrastructure will select which assembly to probe for resources based on the runtime CultureInfo.
Related
I am writing code that is used in both WPF and Silverlight. In C# I can use "#if SILVERLIGHT" for conditional compilation, and it works.
In XAML, however, I must resort to use completely different XAML files, since some attributes are simply incompatible. XAML files are 99% a like, and keeping them in sync is a hassle.
I would like to convert them into a T4 template, so I can do things like:
<SomeControl <#=ClipsToBounds()#> />
Where ClipsToBounds() produces different text for WPF and Silverlight. The requirements are:
Intellisense while working on the XAML
Templates generated at build time
The project must be self contained and work on stock version of Visual Studio: installs of various SDKs and 3rd party editors are not
acceptable
Results of the template run should NOT be in source control. -
I found that I can change custom tool on a XAML file from MSBuild:Compile to TextTemplatingFileGenerator and I don't lose Intellisense. However, resulting templates are generated at design time. To have then generated at build time seems like a big pain.
Did anyone have successful experience with this kind of setup?
Only the generic user controls which have generic behaviors across the platforms can be placed in PCL , However,the best suggestion would be keeping separate xaml views for each platform .
Since nobody seems to have suggested a template based solution as desired, I'll share some experience of working with projects targetting both SL/WPF. Many people will suggest using two completely separate XAML files, a different view per-platform, and in many ways this is the "purist" thing to do. But if you want to eliminate duplication, and reduce the risk of your 2 targets drifting apart, I'd certainly suggest sharing the XAML files (with simple project links) can work acceptably well.
There are a few common incompatibilities:
Controls exist in both platforms in different namespaces - subclass your own version and refer to that.
Styles etc. need differ between platforms - include a common dictionary of resources, different per platform, and reference by key.
Controls are substantially different, or present in only 1 platform - introduce your own wrapper control (which may require substantial implementation in the 'missing' case).
Basic properties or functonality missing - can often hack something up with an attached behaviour (eg your ClipsToBounds example is found here).
I know and use two methods to store and access resources on application scope:
Properties\Resources.resx
create a folder and place for example images there, setting their build mode to Resource
What is the difference between the two methods in terms of performance and complexity, when should each be used and how are the resources best consumed in WPF and VB or C# code in each way?
Thanks in advance,
Julian
The "natural" way of referencing resources like images in a WPF project is your second option. You can use a relative URI to point to the image and WPF will lazy load it. You can reference resources in other assemblies using pack URI syntax.
Using Resources.resx will code-generate properties that loads resources when referenced. Resources can be strings, images, icons or a byte arrays. Using {x:Static} in XAML allows you to reference the static properties generated by the code-generator but often you will need a converter to convert the resource type into a type usable by WPF.
There is some support for localization using Resources.resx and if you want to provide a multi-lingual application you could store the translated strings in Resources.resx. However, WPF localization as described by Microsoft is not based on Resources.resx.
For images, the second option is much easier. For strings, the first option is probably easier but instead you could stay in XAML and create a ResourceDictionary.
I would like to provide language support on a WPF Application. To provide support for dynamic contents, I can make use of a language support file.
However, how should I go about doing this for Static texts, such as those found on XAML.
For example:
<TextBlock
FontSize="20"
FontWeight="Bold"
TextAlignment="Center" FontFamily="Helvetica">
Start Process
</TextBlock>
in the code above, the text "Start Process" is static, but how would I integrate different language support for that text.
Using genercal globalization and localization (language specific support) in WPF apps ... https://msdn.microsoft.com/en-us/library/aa292205(v=vs.71).aspx
Using locale specific resource files in .net .... http://www.c-sharpcorner.com/UploadFile/ankithakur/Globalization_Localization_in_DotNet_CSharp07032006023510AM/Globalization_Localization_in_DotNet_CSharp.aspx
Using x:Static attribute in XAML to achieve binding of resource (.resx) texts ... http://robertoschiabel.wordpress.com/2010/01/31/wpf-add-localization-via-resx-files/
LocBaml is a tool, microsodt has provided explicitly for fast language support for WPF.
This tools adds Uids for every xaml tag and helps you to enlist those tags in CSV files (with some common properties).
These CSV files then can be easily used to provide translations in different languages.
There are certain disadvantages with this approach. Like, you will not get dynamic language switching with this. Sometimes, maintaining CSV files can be cubersome.
Please refer this Link
Well, Angel's advice is on target, especially the last link for using x:Static. There is also a nice really article and code sample that uses this technique here
What I like even better, currently, is a markup extension. A good example of one is here).
Localization is actually a fairly complicated affair even though it seems like you just want to say "Start Process" in Russian! I suggest you stick with the first Code Project article, and only that one, until it makes sense.
Than taking in the second article will be easier.
Last piece of advice I have is to not waste your time with LocBaml.
Cheers,
Berryl
In WPF applications all the views are inherited from System.Windows.Window and have an associated xaml and codebehind file. That seems logical.
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)? I know that this file is usually used to define application resources, etc, and xaml provides an efficient way of defining them. But that can also be done programatically. Then what benefit did the designers of wpf achieve by having both the xaml and code behind files for "App"? Wouldn't one of them have been enough?
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)?
Remember that XAML is not a UI language, but a general declarative language. While it's true that it's mostly used to represent UI for WPF or SilverLigth, it's also used to declare graph of objects in other non-UI technology.
The first example that comes into my mind is the Workflow (the XOML is a derivate of the XAML), SharePoint also use XAML in some hidden parts, and I've seen in a customer project with use XAML as a meta-language for generating web-apps (and yes, it actually outputs HTML).
Then, to answer to your question, the application have both files (and it is not actually a requirement) because you can :
declare some objects (in the xaml)
override the behavior of the application (by overriding appropriate methods)
Designers can specify resources for entire application without entering any code and use it in any Window. Its something like a root for all windows. For example, if you use one style for every TextBox (or any other control) in every window, you can specify it in App.xaml and bind anywhere without duplicating.
Does anyone have any best practices or experience of localization in Silverlight. MSDN recommends binding the resource to the XAML, but the result is pretty messy:
<TextBlock Text="{Binding Path=Resource1.HelloText, Source={StaticResource LocalizedStrings }}"/>
A page of that is going to make the XAML unreadable!
Any shortcuts?
I asked a similar but more complex question a while back (silverlight paramterised resource values for internationalisation)
The example given on MSDN is really insufficient for serious localization, it assumes every string is entirely present and has no parameters, the reality is you will have values you wish to embed within the string but need placeholder to mark the location of that variable in the string so a translator can move the marker as they translate.
You can achieve a more advanced mechanism by implementing multi-binding yourself into silverlight - Colin Eberhardt did a nice implementation (silverlight multibindings how to attached mutiple bindings to a single property) - adjusted a bit and combined with a MultiValue Converter you can perform multiple bindings, allowing the first binding to be to the language file, and subsequent bindings to be to the parameters to be embedded.
It's quite a pain but the localization story is just noticably lacking - even chatting at the PDC09 over silverlight 3 / 4 there is really not a great route at present in place - if WPF multibinding makes it across to SL4 that makes it slightly easier, but I havn't seen a good alternative implementation as yet except for people outputting all the strings from the ViewModel - which seems wrong form the 'designers' perspective.
I agree that Microsoft recommendation for Silverlight (and WPF and Windows Phone) localization is very rudimentary. It has several issues. Most important are
It is hard to edit main maintain two separate files: XAML and RESX
Your loose great part of string content when you move it from XAML to RESX
XAML becomes much harder to read and maintain
The reason for this is that Microsoft tools such as Visual Studio, does not provide any way to localize XAML. An easy solition here is the localize XAML and include the localized XAML along with localized RESX into satellite assembly files.
<TextBlock Text="Hello World"/>
is much easier to view, edit and maintain than
<TextBlock Text="{Binding Path=Resource1.HelloText, Source={StaticResource LocalizedString }}"/>
+
<data name="LocalizedString" xml:space="preserve">
<value>Hello World</value>
</data>
What you need to do is to keep hard coding string into XAML and localize the XAML itself. This gets very difficult without a good tool. This is why I recommend you to use a localization tool that can locize XAML. This alone is not enought because if you have localized XAML you still need to compile them into satellite asembly file and finally include the satellite inside your XAP file.
You need to have a tool that can localize RESX and XAML and also compile localized satellite assembly files. There are somes tool that can do that (for example Sisulizer).
If you want to use only Visual Studio then you have to stick with the best practices by Microsoft.