I did my UI settings.Original language is English. After that I set Localizable property to True. Copied original resx file to frmMain.de-De.resx (for example). Translated all strings. Everything works.
But now I would like to change positions of controls. After that changes are visible only for original/primary Culture (En). When I change Culture to de-De then UI controls are on the "old positions"(?!)
Is this normal behaviour? :O I'm unable to change controls positions on my form after localization?
Can someone explain me this and give some best solution. I really have to change UI design but I don't want to manual copy all translated strings again.
If my description is not clear then I can post source code, just please let me know. I use VS 2008.
Greetz!
If you select the form itself in the designer, and look at the properties there should be a field Language.
Leave this to default when designing the form: this is the default layout for languages without a specific layout. Now, if you want a different layout or even different labels for another language, select the correct culture from the Language property and start designing your form.
By doing so, making changes to the default (in your case english) layout will not be reflected on the specific language's form. This is the way it is supposed to work, the layout of languages is completely separate.
Related
I've thoroughly checked the custom controls topic, spent several hours looking into custom controls written by other people. I've written my own custom button, to feel it better. I've read all the google answers around the "why custom controls", "advanced custom controls examples" and such.
My question is, WHY?
Why would I (or anybody) go through 9 circles of hell to create his own custom control, when one can just adjust an existing control to his needs (using styles and templates). I actually didn't find any explanation on google, just tons of examples, mostly from people who sound even less educated than me.
I imagine there IS such need, when talking about some complicated DataGrid with, I don't know, every cell being a button or something (and still I believe I could do it with a regular DataGrid)... But I've not found anything more complex than a beautiful button. Is there nobody sharing a complicated code on the topic?
There are different levels of element customization in WPF, depending what class you extend from. Each has its own uses and is implemented differently. It is not clear from your question if you are asking about a specific type of control or about all of them in general. So, I will tell you what I think about different ones.
UIElement or FrameworkElement
Extending UIElement gives you the lowest level custom control where you have complete control over the layout and rendering. FrameworkElement is slightly higher level as it does most of the common layout stuff for you while also allowing you to override key parts of it. The main idea with these is that they do their own rendering rather than composing other elements together.
I have made a number of custom FrameworkElements over the years. One example is a ruler similar to one you might find in a program like Photoshop. It has a bunch of properties providing customization for how it is displayed as well as showing markers indicating mouse position relative to the ruler (and a number of other little optional features). I have used it in two different professional projects. I think the main benefit is that it is extremely easy to drop in and set properties/bindings on wherever desired. Build it once, use it over and over.
Control
Extending Control introduces the concept of compositing multiple elements/controls into one reusable component via control templates.
I have used this one less often, but still find it very valuable in the right circumstances. Again, the main benefit here is reusability. You create a control with properties that make sense for what you want to do, then hook up those properties to the properties of the controls in it's control template. Really, this is the same as applying a new template to an existing control, with the added feature of being able to define your own dependency properties. You also have the ability to perform custom logic in the control's code if you need to.
I may be misreading some of your text, but you seem to imply that making a custom control is considerably more difficult than making a control template for an existing control. I have found that the two are nearly identical in most cases using this approach, the only difference being whether you have a code behind you can use.
User Control
A user control is really only slightly different from a custom control practically speaking. Only, instead of defining a control template, you define the visual content directly.
This is probably the most common type of custom control. It is basically the standard method for making XAML based content in a WPF application. These can be reused like other controls, but are more suited for single use such as the content of a dialog or window or something else that is specific to a single application.
Some Other Control
You can also extend an existing control to add additional functionality to it. This way, you still get all the features the control offers and only have to implement the additional bit.
For example, I have a custom control called an AutoScrollRichTextBox that extends RichTextBox. So, it does everything a RichTextBox can do. It also has the ability to automatically scroll to the bottom when content is added to the text box (which it only does if the text box was already scrolled to the bottom before the addition content was added).
I could have implemented that feature as an attached property instead of an extension of the control (and maybe I should have), but it works, and I have used it in three different applications (as an output window and as a chat log). So, I am happy with it.
In the end, it really is just a matter of how self-contained, reusable, and easy to drop in you want a control to be. If there is already a control that does what you want, and you just want it to look different, then you should definitely use styles and templates to achieve that. However, if you want to make something that doesn't already exist, limiting yourself to using only styles and templates will make the implementation work harder and make the end result less reusable and more difficult to set up additional instances (unless all instances are identical).
The examples of making things like buttons that look different are not examples of what you should use a custom control for. They are just examples of how someone would go about making a custom control for the purpose of teaching the details of the process. If you actually want a customized button, just customize a button.
I am building a wpf user control to provide navigation facilities for database records.
The control is provided with a set of default images (as illustrated above) which the end user can change is they so wish. In addition the end user can choose to dispense with images altogether. In the event that they select that option (for either one or all of the buttons that comprise the control) I have provided some default fallback text.
This text can also be overwritten by the end user if they so wish, but the default text at least provides them with some basic text that essentially conveys what the button does and saves them having to add text every time they use the control (default tooltip text is also provided).
Now if you happen to speak English, or your intended target audience is English this should work, but it doesn't really cater as is for languages other than English. This I would now like to change.
What reading I've done on the subject of multi-lingual resources and wpf seems to assume that one is talking about the overall application rather than a standalone user control that might be used in different language environments.
I had a talk with a creator of controls who said that making this multilingual would probably involve building several copies of the control for each intended language.
In the light of this I have two questions. Was the gentleman I spoke to correct, should I in fact build multiple copies of this for each language, of is there a way to have multi-language resources within the same copy of the user control?
If the latter is possible what is the correct way to go about achieving this. We will be dealing in total with default texts for eleven buttons (which I will need to be able to refer to in code within the control incidentally) and default texts for thirteen tooltips (which again will need to be able to be referred to within the code of the control).
Take a look on WPF localization extension.
Here's a pretty good documentation for it: link.
You can define your controls' localizable properties, which store their localized values in the satellite resource assemblies.
In your xaml code, define the localized properties with xaml extensions syntax:
<Button Content="{lex:Loc Test}" />
Then, create resource files for each culture your application will support and give them the same name as the main assembly plus the general or specific culture code (e.g. en-US, de, de-AT, ...) before the .resx ending yielding: AssemblyName.CultureCode.resx.
Now, populate the resource files with your localized properties key/value pairs and build the project.
You're done!
I am new in silverlight ,I have more than two textbox in a UI, what i want to do is there will be a textbox with a label secondary name,on that text box when user type anything it should come in arabic language!
I mean when users focused on a textbox control the default language need to change to arabic.
I have seen same questions in this stackoverklow,but the answer i saw was saying how to do resource switching of languages of labels,buttons etc. but my question is how can i change the language when i type in a textbox control,Hope u get my point.
Thank you in advance.
You can do this through an API call if you're trying to put the translated text into the label. This link shows example code on how to use the Bing Translation API in Silverlight.
I experience strange things when setting the "Language" property in WPF:
Set FlowDirection to "RightToLeft" on a Window or textbox/textblock
Set the Language property to "fa-IR"
Set the text to one of the sample texts below (A, B)
A. This text does not render correctly in WPF 3.5:
فاکس: +44 1908 215040
It works with WinForms and Silverlight. Note that it contains a 'LEFT-TO-RIGHT MARK' (U+200E)
Here is a HTML version of the above with numeric character references to LRM, to visualize where the LRM is inserted:
فاکس: +44 1908 215040
B. This text does render correctly in WPF:
فاکس: +44 1908 210210
But it contains (I believe) unncessary LRM characters. I put together the text in a trial-and-error fashion.
Here is the HTML version with the extra LRM characters
فاکس: +44 1908 215040
Why are the extra characters needed / what am I doing wrong with the original text?
Note: The problem occurs IFF setting the Language property, either explicitly in XAML or code (like Language="fa-IR") or by overriding the default value of the Language property in code (assuming current culture being "fa-IR") as so:
FrameworkElement.LanguageProperty.OverrideMetadata(typeof(FrameworkElement),
new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));
If I leave the language property as en-US, the text renders correctly in WPF, but I really need to set the Language to have value conversions work without having to set the ConverterCulture explicitly on each and every data binding that could be binding to some culture dependent data.
There are also other problems, like LRO ('LEFT-TO-RIGHT OVERRIDE' (U+202D)) being ignored.
I really need help understanding what is going on, as this could turn out to be a show stopper for localizing my application to Persian and Arabic.
I suspect that I am the one doing something wrong, as I fail to google for the problem.
Here is a a related post on MS Connect, but no one has so far confirmed the behaviour as a bug:
http://connect.microsoft.com/WPF/feedback/details/682784/incorrect-unicode-bidi-behaviour#
Note: I am not that familiar with the BiDi algorithm in general and know even less of the actual implementation in WPF. I have a basic understanding of Unicode.
I wanted to know which one amongst Style and UserControl would be better to use in WPF?
For example:
I have created an image button in two different ways.
One uses Style and ContentTemplate property is set.
It uses one other class with dependency properties.
The other way is I have created a UserControl which has a button and its content property is set.
The file UserControl.xaml.cs also contains the dependency properties.
For Code details see the answers of this question:
Custom button template in WPF
Which one would be better to use? In which scenario should one go for Style or UserControl or any CustomControl?
Styles are limited to setting default properties on XAML elements. For example, when I set the BorderBrush , I can specify the brush but not the width of the border. For complete freedom of a control’s appearance, use templates. To do this, create a style and specify the Template property.
Styles and templates still only allow you to change the appearance of a control. To add behavior and other features, you’ll need to create a custom control.
For example,
To create a button like a play button use styles and templates, but to create a a play button which will change its appearance after pausing it use UserControl.
For this type of thing I would go with Style, even though I'm not really adept with graphical tools. I tend to produce a basic, boring style that I can get started with and then prettify it once the application functionality has been verified.
The nicest thing about WPF is being able to distance much of the graphical look, feel and behaviour away from the code.
This allows you to change the style of your application without revisiting the code and indeed means that you can change styles on the fly at runtime.
There is an awkward line to tread with regards to how much behaviour is placed within the XAML and how much is placed within the code. A rough guide would be to decide on what behaviour must always be present within the UI and place that in the code, everything else place within the XAML.
Think of the code as being an abstract class with defined interfaces and the XAML Styles as being classes based on that class and you'll get an idea of what I mean.
Conversely, I know that people who are far more adept at the GUI work prefer to put more functionality in the XAML and others who prefer the code side, because they find the GUI work slow or difficult.
When thought of that way you'll see that there's never really a right or wrong answer, just better solutions that suit your skills.