Localization problem - language selection persists
Posted: Wed Oct 19, 2016 4:44 pm
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
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