Do not Use App-V for Legacy Locale/Regional Settings Compatibility – Use AppLocale
Recently, we have had some customers asking us about leveraging App-V to virtualize locales. You may also refer to them as regional settings. Since Windows 2000, the Windows operating system has been multi-locale aware and is able to preserve user-specific locales.
The user locale determines which default settings a user wants to use for formatting dates, times, currency, and large numbers. The user locale is not the language. The only influence the user locale has on the language is on the names of the days and months. For example, if you use the long date format to display “April 22, 2010,” the “April” string will change based on the user locale.
Changing the user locale automatically adds an Input Locale with the default settings for the associated language. I made some serious tests involving easily discernable applications with regional setting differences (locale differences.) While the operating system now support user locales, there are still legacy applications that only recognize system locales. Some of these applications may be hard-coded to correspond to a specific locale.
App-V is language or locale neutral and should have full support for different languages and character scripts, sorting orders, time/date/address formats, various International keyboards and global Input Method Editors (IME), and other locale settings. This approach is called “single World-Wide binary”.
It is important to understand that while we are locale aware, the actual isolation and sandboxing of the locale regional settings takes place at a system level even though the preferences are stored at the user profile level. App-V is not expected to make the application localized or culture-aware if it’s not already supported. It won’t make the application to work on a culture that the application does not originally support in the locally installation.
If it were as simple as simple as making registry modifications within the virtual environment, this may would work. Most locale-aware applications, however will actually call API’s directly in Windows whether they are user locales or system locales. For example, retrieving the user locale by calling GetUserDefaultLCID and the system locale by calling GetSystemDefaultLCID. When the application is calling the API directly, it is not reading the registry entries because it is calling the Win32 API directly and it will be querying the registry – but outside the virtual environment.
We recommend that users look to the AppLocale Utility as a possible remediation. The AppLocale utility allows users to run a legacy application without changing to the code-page/system locale needed by that particular application. AppLocale emulates the code-page required by that legacy application without changing the machine’s system locale. This can provide the “sandbox” you may need for the application’s locale.