Localizing general ReportViewer strings in Reporting Reporting

shovavnik

39 posts

Member since:
Aug 2007

Posted 08 May 2008 Link to this post

Is there any way to localize the strings used by the ReportViewer.

This includes the "Generating report..." message, the text and tool tips for the toolbar buttons, the text for the "zoom" drop down items (and others I may have missed).

Svetoslav

Admin

649 posts

Posted 08 May 2008 Link to this post

Hello shovavnik,

Please review the Localizing the Telerik Report Viewer KB Article that describes how to localize both WinForms and WebForms report viewers.

Greetings,
Svetoslav
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

shovavnik

39 posts

Member since:
Aug 2007

Posted 08 May 2008 Link to this post

I've created a translation for Hebrew, per the instructions. But the translation is not being loaded.

I've verified that the CurrentUICulture is "he-IL". I've tried with both "en-US" and "he-IL" for CurrentCulture.

I named the resx file: Telerik.ReportViewer.WinForms.Resources.he.resx. I also tried "he-IL "instead of "he".

1. What am I missing?

2. Why doesn't telerik simply expose Localizable string properties on the ReportViewer controls that can be localized with the form instead of separate resx files that can't even be embedded?

Svetoslav

Admin

649 posts

Posted 12 May 2008 Link to this post

Hi shovavnik,

Please make sure that you use the appropriately named resource files according to the ReportViewer you use:

For the Web Forms Report Viewer, the names of the RESX localization resource files should have the following format:

Telerik.ReportViewer.WebForms.Resources.[culture].resx

For the Windows Forms Report Viewer, the names of the RESX localization resource files should have the following format:

Telerik.ReportViewer.WinForms.Resources.[culture].resx

Also please make sure that the RESX file is located in the correct place according the the KB article.

If you still experience problems, please send us the complete application so we can examine the actual reason and get back with a proper solution.

Regarding the 2nd question - our primary goal when developing the Telerik Reporting engine is to stick with the standard patterns as much as possible. Unfortunately we cannot use the pure .NET approach with the satellite assemblies because they should be signed with the Telerik's private key which is not an option. So we decided to workaround this limitation by utilizing the RESX files without the need to be compiled in an assembly. Otherwise using properties for every string we need to localize will cloak the ReportViewers' API.

Greetings,
Svetoslav
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

David

15 posts

Member since:
Feb 2008

Posted 12 May 2008 Link to this post

Hi guys,

It's True that expose a property for ever resource that someone need to localize is a very bad practice but...

I suggest you to expose one unique shared property that is a namekey pair collection of strings (system.collections.specialized.namevaluecollection).
We fill this collection at begin of the application with the keys you expose and the apropiate translated strings and then every instance of the viewer read use the shared property to be localized.

I think it's clean, solves the problems of the resx file, it's highly scalable and it will offer us to change the language without need to especify cultures on each instance of viewer and sublibraries and without need to provide many resx files that can be openened and edited on the clients machine.

It's only an idea... :P

David Tomás

shovavnik

39 posts

Member since:
Aug 2007

Posted 12 May 2008 Link to this post

I can't send the complete application, but I created a small sample that reproduces the problem. The thread does not allow me to upload it though.

shovavnik

39 posts

Member since:
Aug 2007

Posted 12 May 2008 Link to this post

How does my suggestion deviate from any .NET pattern?

The idea is to create properties with Localizable attributes. Lots and lots of localizable properties like this exist in .NET. The assemblies can be signed or not signed, and the resources are stored in the resx associated with the form on which the control resides.

This solution lets you load strings at run-time through code and edit them with the designer like any normal control. It also does not require code and supports a single-assembly configuration, which is a requirement for most of the projects I work on.

David's idea to use a NameValueCollection sounds like a good idea and is scalable, but it's definitely not a standard solution and it's not really usable for my purposes.

shovavnik

39 posts

Member since:
Aug 2007

Posted 12 May 2008 Link to this post

I forgot to mention that my solution also enables localizing the ReportViewer as an inherited user control. The user control itself can be localized using its own resx (similar to the form's).

And one other advantage of my solution over telerik's is that it is impossible with telerik's solution to use DIFFERENT localizations for the ReportViewer in the same project. That is, if I want to have 2 different instances of the ReportViewer (2 forms, each containing a different ReportViewer), and I want to localize them differently to the same languages, telerik's solution can't support this. For example, I could easily envision a project that has two different report forms, one of which has "Refresh" for the refresh button and the other "Reload". This will become even more evident when you make the toolbar more extensible (as mentioned elsewhere in the forums).

Svetoslav

Admin

649 posts

Posted 13 May 2008 Link to this post

Hello shovavnik,

Yes it is not possible to have different strings in different ReportViewer instances and this is by design. As far as the accessibility and usability are considered, it is a poor practice to have different names for similar things. Anyway if there is a good reason and valid real-world scenario where this would come handy, we can reconsider our decision and look for a better solution.

The localizable properties approach allows you to localize only one report viewer at a time. In case your application utilizes more than one report viewer (which is a common scenario), you have to translate all resource for all report viewers separately. We consider this limitation as a serious disadvantage, which makes us believe that we have chosen the right approach.

The other approach that David suggested is very similar to the RESX one, since the RESX file contains exactly the same name/value collection he talks about, but in XML format.

In order to find the best solution for localizing the report viewers' resources I am kindly asking you guys to use this forum thread to summarize all common pitfalls and problems you are experiencing with the current implementation. We will review all of them and get back to you with our opinion on the matter.

Thanks for the involvement!

All the best,
Svetoslav
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

shovavnik

39 posts

Member since:
Aug 2007

Posted 13 May 2008 Link to this post

With all due respect, I think you're looking at this all wrong.

When you use two labels, they are "the same", but no one would expect them to always have identical text (even in the same language). The same goes for any control, including the ReportViewer.

Furthermore, the more flexible you make the control (as I'm confident you will), the more "different" different instances of the control will appear. For example, in an application that manages permissions, the tooltip for the "page settings" button might be "Page Settings" for a user with high privileges, or "You cannot change the page settings because you do not have permissions" for a user without them.

Another popular example is a multi-portal site or a similarly complex windowed application, in which different portals allow END-USERS to specify their own strings for THEIR users.

In the application I'm currently working on, I hid all the buttons on the toolbar and created my own toolbar to support this kind of behavior.

By utilizing .NET's standard resource mechanism, an application developer can use extant mechanisms for loading strings into the control. .NET supports the following mechanisms (and more), for which an alternative will have to be found just for the ReportViewer:
1. Using form resources.
2. Using user control resources.
3. Using additional embedded resource files, satellite assemblies, or resources loaded at run-time from sources that are not available at design-time.
4. Differentiating between different instances of a control (as demonstrated above).
5. Single-assembly applications.
6. Hiding resources and implementation details from end-users (the ReportViewer's resx file is easily accessible to any editor).

Any developer that needs to make sure different instances of a control support use the same strings, already has the mechanisms to do it. This isn't different than any other resource-usage scenario.

The point is that all of telerik's controls are among the most customizable controls out there, because telerik cannot foresee all the different possible uses ahead of time. That's what stands behind the TPF, for example.

So the question is, why is telerik not espousing the same philosophy with the ReportViewer?

Svetoslav

Admin

649 posts

Posted 14 May 2008 Link to this post

Hello,

If I understand correctly, you are actually talking about the customization of the ReportViewers and not their localizations which are different. As far as the customization is concerned, your scenario makes sense and we will definitely consider a better way to enable it. I will add this in our TODO list and we will have it in mind when working on the next version.

Thank you for the involvement.

All the best,
Svetoslav
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

shovavnik

39 posts

Member since:
Aug 2007

Posted 14 May 2008 Link to this post

I appreciate your adding it to the TODO list. This will significantly improve telerik's report offering.

I do not want to mention that while on a micro scale localization and customization are two different topics, in practice they usually go hand-in-hand if not completely inseparable.

I say this with some experience. Almost every application I build is multi-lingual. They range in complexity from simple applications that only need design-time localization and no customization (for example, calculators of various sorts) to complex multi-tier applications that require end-user customization and localization (including customizable multi-lingual web sites).

Thanks for your attention on this matter!

Naveena

9 posts

Member since:
May 2018

Posted 15 May 2018 in reply to Svetoslav Link to this post

May I know the what is KB article and Is this possible to localize the telerick report templates? pls given me sample example for the localization of report designs.cs

Silviya

Admin

318 posts

Posted 18 May 2018 Link to this post

Hi Naveena,

If you need to localize your reports, we use the mechanism described in the Localizing Reports help article. The article elaborates how to localize reports with RESX files through the Visual Studio Report Designer or create a user function in addition to localizing the XML based documents in Standalone Report Designer.

To localize the HTML5 Report Viewer resources, check the HTML5 Report Viewer Localization help article. To modify the HTML5 Viewer's text resources (toolbar, Preview, Parameters and DocumentMap areas), you will have to set the viewer's templateUrl. For more details, check Providing Custom Templates and Templates Structure help articles. An example template could be found in viewer's telerikReportViewerTemplate.html file, which can be customized per your needs.

As an example, you might review Product Catalog Demo located in Telerik Reporting local installation folder: C:\Program Files (x86)\Progress\Telerik Reporting <VERSION>\Examples\CSharp|VB(CSharp)\ReportLibrary\ProductCatalog. It demonstrates how you can bind report's culture to a parameter passed by end-user so the culture can be changed dynamically.

Regards,
Silviya
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items

Naveena

9 posts

Member since:
May 2018

Posted 21 May 2018 in reply to Svetoslav Link to this post

Hi, Admin

The following string is in my RESX file , the functionality of \n,"+" is still displaying in the report pdf , can you let us know how do i vomiting the functionality of those special characters?

" There is no data to display for any Scored Assessments<br/>See the next page for Pai"+\n+", Activity and Sleep Category Scoring(es

Naveena

9 posts

Member since:
May 2018

Posted 21 May 2018 in reply to Silviya Link to this post

Hi, Admin
The following string is in my RESX file , the functionality of \n,"+" is still displaying in the report pdf , can you let us know how do i vomiting the functionality of those special characters?
" telerik is good<br/>See the next page for Pai"+\n+",duty;

Naveena

9 posts

Member since:
May 2018

Posted 21 May 2018 in reply to Silviya Link to this post

Hi, Admin
The following string is in my RESX file , the functionality of \n,"+" is still displaying in the report pdf , can you let us know how do i vomiting the functionality of those special characters?
" Telerick is good <br/>See the next page for pa"+\n+"

Silviya

Admin

318 posts

Posted 23 May 2018 Link to this post

Hi Naveena,

Based on the provided information, it is not clear what report item is used. Is it a TextBox or HtmlTextBox for displaying these strings and as if they are static strings or coming from a data source? Also, I'm not sure why you are using these special characters instead of just add the new line (Shift + Enter) in the RESX file value box. Note that, "\n" would be considered as part of a string, not as special character. As for the <br/> html tag, it would be processed only from HtmlTextBox items.

Please elaborate more on your current scenario in order to help you better.

Regards,
Silviya
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items