Localization problem - language selection persists

[RossAFaneuf]

Our web application sets the language for StiWebViewer using this line of code:

StiReportWebViewer.GlobalizationFile = "Reports\\Localization\\" + lang + ".xml";

Where lang may be set to, for instance "en" or "fr". The language setting comes from the localization choice of users when they login to the application.

The problem is that the first login sets the localization file correctly. However if, using the same web browser instance or even a different instance on the same machine, the localization info does not change, but the info set the first time the above line of code runs persists.

We are using version 2016.2. Earlier versions did not have this problem. In particular, 2016.1 works correctly. Our Quality Assurance department is insisting that we not use 2016.2 until / unless this problem is fixed.

This may sound like an artificial situation, since typical users will login from different machines, and will usually not change their language preference. However this happens during (i) testing by implementors (ii) testing by Quallity Assurance (who are unforgiving) and (iii) some situation where our application is accessed from public machines.

Resetting IIS (iisreset) fixes the problem, so wherever this information is not being reset can be cleared. Obviously we are not going to reset the web service in order to fix this problem.

I have looked at the following to try to figure out where this information is being persisted:
- reset StiOptions.Configuration.SearchLocalizationFromRegistry = false;
- No entries in Application object
- No entries in Cache object
- No temp files that I can find

[Alex K.]

Hello,

We couldn't reproduce this bug.
Please check our sample project and if needed make changes in accordance with your project, what would we have been able to reproduce the issue and prepare a solution for you as soon as possible.

Thank you.

[RossAFaneuf]

Hi Aleksey -

Thank you for providing the sample project. I built this project and as you say, it certainly works correctly.

However, my code, while essentially identical to yours, continued to work incorrectly. I changed the code slightly to the following, and now it works. The difference is instead of setting Localization to the directory + file name, I just set it to the language name.

StiReportWebViewer is an instance of StiWebViewer
Our localization files are in \Reports\Localization. In my testing, the variable 'lang' is either "en" or "fr".

In other words, this fails:
StiReportWebViewer.Localization = "Reports\\Localization\\en.xml";

And this succeeds:
StiReportWebViewer.Localization = "en";

I'm happy if I have code that works, but I am interested in knowing why it works. And also why the recommended code worked correctly in 2016.1 but not 2016.2.

Thank you again.

Here is the code:

// Get DataSet & register in report
DataSet ds = ReportHelper.Instance.GetDatasetForReport(stiReport, SessionManager.SessionReportsContext, report.ContentTypeReportFilter, false);
stiReport.Compile();
stiReport.RegData(ds);

// Localization
string lang = Thread.CurrentThread.CurrentCulture.Name.Substring(0, 2);

StiReportWebViewer.ResetReport();
// Version 2016.2: This should work but doesn't
//StiReportWebViewer.Localization = "Reports\\Localization\\" + lang + ".xml";
// Version 2016.2: This is not documented to work but apparently does
StiReportWebViewer.Localization = lang;
StiReportWebViewer.Report = stiReport;

[Alex K.]

Hello,

In the release 2016.2 WebViewer component has been fully updated, so localization and other algorithms work differently. For loading localization from xml file (after checking the correctness of the file name), we use the method:
localizationFile = HttpContext.Current.Server.MapPath(path);

Perhaps due to the configuration of your project, use a relative path to the file, so MapPath() method creates the wrong path. In previous versions, this method was not used.

Thank you.

[RossAFaneuf]

Hi Aleksey -

Thank you very much for the information about HttpContext.Current.Server.MapPath(). This change in 2016.2 was the cause of the problem. For the case I described, the page is in .\Reports, so the correct path is \Localization\fr.xml, not \Reports\Localization\fr.xml. I modified the code to use a relative path from the page locations in the application, and now localization works correctly.

Thank you again.

[Alex K.]

Hello

We are always glad to help you!
Let us know if you need any additional help.

Thank you.