I am just starting out with Windows 8/RT app development using C#/XAML and am trying to learn about string resources. I've got a string that I would like to use both as button content and as textblock text. In the examples that I've seen, it looks like I would need to define two different strings in my resource file named something like "myButtonString.Content" and "myTextBlockString.Text". Ideally, I'd like to define my string once in the resource file and use it wherever I please. Is there way that I can define a single resource with a name such as "myString" and assign it to both my button content and my textblock text via xaml? If so, how can I do this?
As a point of reference, this is the resource that I got my initial info from.
I recommend you to use Portable Class Library.
Localization can be shared between the Windows Phone <-> Windows Store projects
It's visible at runtime in xaml editor
You'll use it in the same manner at the both platforms.
It's generally easy, just follow these instructions.
One thing to remember - you should create one line resource file in the WS project for the each language. Otherwise VS will not include them from PCL.
Here is a link to globalizing labels. The same can be used with any UI component. Instead of using whatever.Text="My Button" use whatever.Text=resources.labels.lblMyButton. Your resource files are based on a default resource, for example labels.resx. When the threads culture changes then the appropriate labels_ISO_CULTURE.resx will override whatever is defined in the default.resx.
Take a look at this example.
Related
I am creating a wpf application which contains several self contained plugin dlls which are accessed by my main application. Is there any way to provide localization support such that all the localized strings comes from inside the dll?
Example:
Main app accesses Plugin1 or Plugin2 using predefined interface according to the scenario.
Plugin1 and Plugin2 performs entirely different functions depending on the case and displays corresponding strings from inside the plugin dll. (These strings has to be localized to current culture)
Note:
1. Once setup, main app should not have any changes for a plugin change (obviously)
2. Plugins should not have resources outside
Thanks
I may be missing something, so correct me.
In my shop we simply include resource files in the referenced DLLs. We take those resource files and send them to a translation service. I think as long as you're storing all of your localizable strings in resource files, as opposed to hard coding them, you should be ok in terms of localization.
Another thing to consider, however, is screen real estate. Some character sets take up more space than others. This is usually a problem for us when we make the translation from U.S. English to Chinese.
I've been working on a WPF control for a few weeks now that contains a XAML-drawn map and has the ability to zoom in / out and pan the map. Also, it contains a converter that converts screen coordinates to lat / long coordinates which works pretty nice, however, the converter works based on few constant parameters that should be available when the application gets loaded.
Right now, those parameters are loaded with the non-XAML map file (.dwg file) which requires me to have a reference to an external library and the loading of the file takes up a few seconds when the application is loading for the first time, which is kinda annoying.
I wanted to store that information as constants in my C# code-behind for the XAML control, however is there a way to embed those constants in the XAML itself? Since the control should be as generic as possible and should support all maps that I will give it in the future (each having different parameters) I want the code to read the parameters from the XAML file and use it in the code.
If I wasn't clear in my question please let me know.
You may want to look at this article. It is about Silverlight but it should be applicable. This Code Project article may be of some use also.
I have an application lets say "Application1" .I want to install same application but by changing some contents in it and also its name like "Application2" so that both application1 and application2 can be seen on device?
Is this possible?If yes,then can someone kindly help as to how to do it.
EDIT:
Just if somebody else might need it, I got this done.
Get a GUID from a GUID generator tool and use this new GUID in WMAppManifest.xml and replace ProductId in this file and GUID in AssemblyInfo.cs.Rebilud the solution and its done!
Creating a new app with exactly the same content is very easy:
Create a new project and name it with the new name.
Remove the pages/classes created by default in the new project.
"Add as Links" all the pages/classes from the original project.
If you want to have different content in the second app, just put the different content in a separate file and use that rather than a linked one. (Partial classes split across multiple files make this very easy.)
Another way to customize content in the second app is to define a partial method in the original app but only implement this in the second app (in a partial class/file which only exists in the second app). In the implemented partial method add your changes to override the default (original app) behaviour/layout/whatever. - This is a good way of altering pages where you don't want to have to put customization into an already existing app. You just "override" it in the second app.
You would need to submit the two slightly different applications to the market as separate applications in order for them to be seen on the user's device.
As Matt suggests, if the two applications have a lot in common, then you can use linked files to reduce your maintenance overhead.
In addition to Matt's suggestion, I've done this for Free/Paid versions of the same app.
It's pretty easy to do. The files to change between versions are:
the icons
the splash screen
the mobile XML file in the Properties folder
The important thing in the XML file is the GUID identifying your app. This GUID doesn't seem to be used in the Marketplace - but it is used by the debugger's deployment functionality.
You can also use a project level #define to include/remove any other code you want different between the projects.
I want to add culture to window application so that it can be used globally.
For this I want to use Only one Resource File.
Right now what I do is adds control manually to that file and reads them at page load.
I want this thing to become automated.
How should I proceed
The .Net model is to use a different dll per culture, so if I understand correctly, you're not going to be able to use .NET i18n.
I have thought of three approaches to create and maintain resources in .Net projects for WinForms using Visual Studio 2008. (I am sure there should be more than three ways.) I need to decide on one before starting to implement internationalization for our product.
Have individual sets of resource files (resx) for each windows form or piece of UI (a custom control) in each .net project. These are auto generated by Visual Studio when Localizable property is set to true in the form or control properties.
Have one resource file per .net project. This is added manually and updated manually with the resource strings and messages.
Have one resource manager project that has resources for all the components for a set of .net projects.
Personally, I do not like the first approach as it creates numerous resources files. The only advantage we get in this approach is that we do not need to set text in UI elements manually.
I like second and third approach as they are easy to maintain and there is only one set of resources that you need to handle. So no duplication of strings and messages. Easy for the translators also.
What are your thoughts? Please share.
I have tended to use VS to create the project and provide the default set of resources but then maintain any additional resources outside of visual studio via the SDK tools winres.exe, resgen.exe and al.exe.
You can maintain the resources in a fairly simple folder structure of one folder per culture and just have a batch file or two to build the resources into satellite assemblies. This gives you the advantage of keeping the VS solution to the core product and all localisation can be done after the fact.
If internationalizing your app means more than translating pieces of text you should go with the first one. You can create satellite assemblies to deploy different cultures. This way you are not localizing just text but also images, control layout, etc. This is the way how Microsoft recommends it and they have good reasons for taking this approach.
I've found that the simplest approach to internationalization is to simply maintain a list of all the different pieces of text in your application (labels, buttons, form captions etc.) in a spreadsheet or tab-delimited file of some sort, and then send this file to the translators to add (in one additional column for each language) all the translations.
You then call a simple method in the Load event of each form (which are all maintained in English) that iterates through all the controls on the form recursively and changes their Text properties to the translated values for whichever language you're translating the app into. The language can either be determined programatically (I forget where in the .Net namespace this is indicated), or you can have a simple language selection dialog when the application first starts (the advantage of this second method is that your app can be translated into whatever language the user wishes, without having to set the language for all of Windows - this is especially useful for kiosk applications).
In my opinion, creating and maintaining all the different internationalized versions of every form is a major pain, although it is useful when the translated text values are significantly different in size from the English versions.
Personally, I prefer the first approach because the context (in your case, the forms) is very important for a translator to do his job perfectly. In your second and third approach, the context is gone because it is just a list of strings.
Yes, the first approach can be a pain to maintain but at least your application would be translated correclty.
I personally love to add a single project .Resources.
Next I enable Microsoft MAT ( https://developer.microsoft.com/en-us/windows/develop/multilingual-app-toolkit ) and manage all my translations via MAT.
This way you can also recycle translations from other solutions, saves you time ;-)