7 Answers, 1 is accepted
Currently RadControls for WinForms do not provide any dedicated localization features. The features you expect are included in our todo list for the next release.
Any feedback on how do you expect localization features to be introduced are most welcome.
Regards,
Mike
the telerik team
Rank 1
Since I posted this message I took the first step toward localization, which is to set Localizable = True. Then I looked at the Designer code and you appear to have a huge, impossible, must fix, show stopper bug that you need to get into your Q1 release. I’ll give you additional localization feedback, but I first want to focus on this bug.
The bug is in your code generation – emitting the designer code. Here’s the code you emit if Localizable is set to true:
resources.ApplyResources(Me.moduleRibbonChunk, "moduleRibbonChunk")
Me.moduleRibbonChunk.Items.AddRange(New Telerik.WinControls.RadItem() {Me.moduleGalleryElement})
Me.moduleRibbonChunk.KeyTip = ""
Me.moduleRibbonChunk.Orientation = System.Windows.Forms.Orientation.Horizontal
Me.moduleRibbonChunk.Text = "Module"
Me.moduleRibbonChunk.ToolTipText = Nothing
The problem is that you’re setting the Text value, ToolTipText value and KeyTip AFTER the call to ApplyResources. The purpose of ApplyResources is to set the localized versions. I can set them to French (for example) but you immediately smash them back to English.
I'd like to be able to localize everything, so I'd like Orientation also to be set through the ApplyResources and not set back.
For reference, here is some code from a .NET toolstrip.
Me.CommandToolStripButton.DisplayStyle = System.Windows.Forms.ToolStripItemDisplayStyle.Text
Me.CommandToolStripButton.EnableLinkItem = Nothing
resources.ApplyResources(Me.CommandToolStripButton, "CommandToolStripButton")
Me.CommandToolStripButton.Name = "CommandToolStripButton"
Note that DisplayStyle and EnableLinkItem are set before resources, thus allowing them to be overwritten by ApplyResources, but assuming that will not be done – I’m guessing because WinRes doesn’t support them. The Name is set after ApplyResources because it’s appropriate to block ApplyResources from changing it by resetting it. For each property, three things can happen – the property can be stored in the resx file by default (most properties of the .NET button), not stored in the resx file and set before the ApplyResource call, in which case custom resource managers can override the value, or set after the ApplyResources call in which case no resource manager can change the value in InitializeComponent.
There are some very ugly work arounds, like resetting all text on the form manually after InitializeComponent completes, but this is a really big problem for us. Can you commit to fixing it in the Q1 release?
Rank 1
Thank you for the opportunity for input.
I would suggest you make sure that your team thinking about localization has read Guy Smith-Ferrier's book - every word.
I have only looked at strings so far, and assume normal resource file usage would work for alterante images where required. I would also expect your tools to cover for me as much as possible on any of the gotcha's in other languages and handle rtl perfectly. Colors are another issue that we may or may not have to deal with.
I think those expectations are normal. We have high demands revolving around strings and include:
- programming team/translators OR users localizing application
- both localization and customization needs (all languages and by site with replication)
- no redundancy - strings need to be translated once where possible
- translating data as well as UI
- users can add new data fields that need to be localized
You may not be able to solve all these problems. My approach with .NET, and what I expect to start with your controls is to set Localization = True. I’ve separately reported a bug in your emitted code on that.
My resource approach includes a two stage process where the user (or translator) enters data in a friendly and normalized structure that allows multiple application points (forms/controls, classes/properties) to point to the same translation sequence. I then denormalize into a structure that mimics the resx structure, but store it in SQL Server for replication and security reasons. To support this I need a custom resource manager.
This is where it gets really ugly and if you could solve this one thing…
Winforms makes it very hard to replace the resource manager in the designer code I’ve sort of done this by putting a dummy component on the form and having its emitted code reset the resource manager. But this component must be first on the form, which is very non-trivial to accomplish. So, if you offered a place where I could set a property or you used a base class that contained an overridable method, or just about anything that would allow me to set my custom resource manager before any calls to ApplyResource I would love you forever. If this is not possible in WinForms 2.0, try to convince someone at MS to fix this in Orcas because the people I talk to there may not understand how serious this problem is. It literally takes the beautiful extensible resource system and makes it useless.
OK, if you can offer an alternate custom resource manager, I think that’s your hook into providing outstanding localization support as time goes on. Basic to this is a solution supporting all WinForms, not just your controls. No one translating cares what is part of .NET and what is part of Telerik.
Many people will want a WinRes style “give it to your translator” type approach because it’s familiar. However, I think TableLayout really changed the picture and that it is a very inefficient way to localize because there are so many redundant occurrences of the same phrase. An approach like that would have zero traction for me, but as WinRes sucks, it could be an interesting product (I don’t know who plays how in this space).
My needs are specific to the fact I’m building an external tool – and I’m not sure that approach would make sense for a product. The one thing I would like and may be available from Charles’ ControlSpy tool (which I have not looked at yet) is giving translators and end users the resx identifier (the form or user control and the control name).
I can fantasize about localization support that included jumps to external editors or support for the two phase approach we expect to take, or custom resource managers that automatically supported alternate stores, but I think that’s probably beyond what you’re thinking.
So, in summary. You must fix the code emitting issue I explained in a separate message in this thread. The next most important thing is helping us set custom resource managers (for the very small number of people that do this, this would be outstanding) and the third piece would be support for entering string values – but what I need for that is likely to differ from what many other people would need.
Thank you for your outstanding feedback.
The features you are describing are quite reasonable and would be of great benefit to all of our customers that have localization issues with the current set up. Here is what we can do in order to improve our controls according to your suggestions:
We will fix the code generation for Q1, as obviously it is not functioning as expected. I think we will be able to introduce those fixes even a bit earlier, in a beta release, so that we have time to tune them up further if needed.
We can research and introduce a new feature for replacing the default resource manager, if it relates to any r.a.d.control on the form. We will be happy to hear and discuss all feedback on this during the process of development. We will also research the availability of this feature in the upcoming Orcas Feb. CTP through our MS contacts to communicate the problems with customizing the resource system and will see what happens.
Again thank you for you time and efforts on those issues. Your telerik points have been updated, just as a token of out appreciation.
Greetings,
Mike
the telerik team
Rank 1
Rank 1
Unless every control on a form will be a Telerik control (not a direction I want to go) its setting the default resource manager that's essential, not just setting it for Telerik controls.
Guy Smith-Ferrier discusses this approach in more detail, or I can discuss it further. Certainly you're covering for a Microsoft screw-up, but its a really big deal that's blocking intelligent use of custom resource managers.
There are several technical issues that we still need to get over. That's why cannot commit that all those extra features will be up and kicking for Q1. As far as I know, currently out keyboard shortcuts system is culture-independent, but these things are also dependent on the OS and platform capabilities. Nevertheless, I can assure you that will try to improve our localization support in order to suite your needs.
Kind regards,
Mike
the telerik team