My programs are mainly client Windows Forms programs, aiming at the Greek market. Recently i decided to “globalize” my applications in an effort to expand my activities. Everything went quite smoothly until i tried to localize reports. I was frustrated because apparently there is no easy way to accomplish that. Well, to be honest, i localized some reports in the past and i used parameters to do it. But in that project the number of reports was small, less than ten, so i went for it without much thought. When you have to translate more than 120 reports, you start looking for more efficient ways. So, my quest begun.
What is out there…
Perhaps the most complete and generic solution is described in this article. The whole idea is to take advantage of some undocumented properties of the report components, like ValueLocID, ToolTipLocID, and LabelLocID. Those are localization identifiers apparently not used by any service or the ReportViewer control. Yet, this solution made me rather skeptical, because there is no guarantee that this will continue to be the case in the future. Another report localization technique comes from this source. It doesn’t use the LocIDs properties and the translated values are stored in the database rather than in resource files. Finally, one can use the RDLC Localizing Helper Class.
Report Localizer
After examining the available alternatives i decided to give a chance to the “Parameters” approach but a visual tool was needed to ease the entire process. I like using visual tools, especially when they are good and free! My favorites are ResEx and the Resource Refactoring Tool. Despite my efforts, i was unable to find anything similar for translating reports. If there is something and i am not mentioning it here, i apologize in advance and i would appreciate it if you would bring it to my knowledge.
Report Localizer is a first attempt to create such a tool. The idea is to deal directly with the rdlc file itself. The first step is to identify those textbox elements that don’t hold expression values. The next step is to generate report parameters, of type string, that will be used to store the localized text version of table headers and other textbox items. Those parameters will be added directly to the <ReportParameters> section of the rdlc file. At the same time, the original text in those textboxes will be replaced by an expression that emits the appropriate parameter value. Next, the new report file will be saved and added to the project, replacing the original. Finally, Report Localizer will generate the necessary c# or vb code for calling the SetParameters() method. When all those steps are completed, Resource Refactoring Tool can be used to export the hard coded strings to a resource file and the ResEx tool to add new locales and translate the string values.
Description of the application and a few screens
Report Localizer is a very basic tool. It has has no complex screens, it doesn’t expose many options and it’s not complete yet. Thus the “0.5” of the version number. At the end of this post I will discuss about what can and what cannot be done with it and the type of functionality that needs to be implemented in future releases. Now, let me describe the features of the program.
The user loads an existing rdlc document by selecting the “Open” option in the “File” menu. The xml document is displayed in an WebBrowser control but the content can’t be edited directly by the user. When the document loads for the first time, Report Localizer identifies the TextBoxes that serve as column headers or text labels and adds their definition into a “GoTo” drop down list. The user can navigate through that list to the TextBoxes. Of course, the user can navigate through out the entire document using the “Find/Search” capabilities of the application.
Defining and adding parameters is done very easily. All the user has to do is to select the option “Generate parameters” in the “Action” menu. Then, a new window appears in which two tables are displayed. The first table has four columns. The first column is the suggested parameter name, the second is the default value, the third is the prompt value and the fourth column exposes an option of whether this parameter should be generated. Always use a prompt value, because if you don’t the parameter will be marked as internal and you won’t be able to access it through code. The second table lists the TextBox items that will be affected by the parameter generation. They may be more than one textboxes for the same parameter, if they happen to share the same text value.
When the parameters are generated, use the drop down list to examine the value of the affected textboxes. Now the report file is ready to be saved. Since this is a very early version of the application, always create a new file and keep the original for back up purposes. Now, the new file can be added to the project and the original report can be excluded. All that remains, is to generate the required c# or vb code. You can define which one of those parameters will be included in the code. This is done with the “Select parameters” option of the “Action” menu. You can make your selection in the new window that appears. Finally, use the appropriate “Generate code” menu command to get your code. This code has to be copied and pasted in to your form or in to your class.
Strengths and limitations
Even with this early release a lot of things can be done. First of all, the Report Localizer speeds up the process of parameter generation. Secondly, the code generation feature does its best to take off the burden of writing “dictation code” yourself; and we all know that “dictation code” is both boring and time consuming. But there are a few things you should bear in mind.
The “suggested” parameter names are “generated” from the initial text values of the textboxes. So it’s best to use proper string values as names, when designing your report. If you don’t, you will have to do it in the stage of parameter generation. You should give the same attention when assigning the default values as well, because those values will be used by the program during code generation.
One serious limitation of this release is that it doesn’t recognize subreports. This is a feature that needs to be implemented next. Why is that serious? Because, subreport parameter values cannot be set inside the SubreportProcessing event handler. You can add a datasource to a subreport, but you cannot set the parameter values directly. In order to do that, you have to include them in the parent report, set their values there and finally pass those values to the subreport. The bottom line is that if you use subreports in your projects, an extra amount of work is needed to localize them with the “Parameter” approach. It’s not as tragic as it sounds, but it’s not a fully automated procedure at this stage.
Finally, you cannot localize tooltip messages with this release. I didn’t include them because i never use them. I know that this sounds selfish, but i was trying to cover my own needs when i wrote Report Localizer. I don’t use tooltips because in my opinion all text in a report must be well defined and self-describing. Reports are documents that eventually will be printed. So, if there is something that requires further clarification, i always use a footnote. In future releases this feature could be added as well, but it’s of low priority.
One last thing… Don’t forget about bugs!! Play safe and don’t overwrite your original files with those created by the Report Localizer. At least not with the current release.
The attachments…
The first attachment is the msi installer of the application. Report Localizer can be used and distributed freely (reqs .NET 3.5). I would be more than happy if you decide to try my application and i would be twice as happy if you find it useful. I would also appreciate it if you report bug problems back to me or give any other feedback you might think is appropriate. There is also a second attachment which includes a small c# solution with localized reports (VS2008). The original reports are also included so that you can recreate the project yourself. I hope you find it useful as well.