Congratulations on the release! The community is eager to start playing around with the final Viewer and SDK.
When you start to roll out localizations for the Viewer, can a single Viewer switch between multiple languages? I imagine that this is what the /Culture subfolder is for, but would be interested to know a bit more about how this is implemented.
Will there be a supported workflow for switching languages within the Viewer? Ie: Can I create a custom tool that changes the viewer's Culture/UICulture, forcing the application to read its UI Strings from the appropriate resource file in the /Culture subfolders?
What is the role of the .xml configuration files in the Culture subfolders? These don't appear to be used depending on UICulture. The Viewer always reads its configuration files from the root /Config folder.
Finally, how would multiple localizations effect Add-In tools? Would my Add-In assembly need its own localization logic and language resource files?
Apologies for all the questions; We're attempting to evaluate the feasability of using the Viewer for multilingual deployments, and any information you could provide would be appreciated.
When you start to roll out localizations for the Viewer, can a single Viewer switch between multiple languages? ... Will there be a supported workflow for switching languages within the Viewer?
"No" to both questions. This is not supported.
The recommended procedure to create an application that supports multiple languages is:
First build the app in one language.
Xcopy the app into separate virtual directories for each language.
In each language app, go to the Culture\<lang> folder and copy its contents and paste in the root directory of the application, overwriting existing files.
Create a page that redirects to the respective language application depending on either the user???s choice or by detecting the browser culture.
What is the role of the .xml configuration files in the Culture subfolders?
It simply contains and stores language files used by the Silverlight Viewer.
Finally, how would multiple localizations effect Add-In tools? Would my Add-In assembly need its own localization logic and language resource files?
In order for an "Add-In" to support multiple cultures, it should use the standard .NET localization procedure of creating resource assemblies for each supported language.
When you start to roll out localizations for the Viewer, can a single Viewer switch between multiple languages? ... Will there be a supported workflow for switching languages within the Viewer?
"No" to both questions. This is not supported.
The recommended procedure to create an application that supports multiple languages is:
First build the app in one language.
Xcopy the app into separate virtual directories for each language.
In each language app, go to the Culture\<lang> folder and copy its contents and paste in the root directory of the application, overwriting existing files.
Create a page that redirects to the respective language application depending on either the user???s choice or by detecting the browser culture.
What is the role of the .xml configuration files in the Culture subfolders?
It simply contains and stores language files used by the Silverlight Viewer.
Finally, how would multiple localizations effect Add-In tools? Would my Add-In assembly need its own localization logic and language resource files?
In order for an "Add-In" to support multiple cultures, it should use the standard .NET localization procedure of creating resource assemblies for each supported language.
Any dates on release for the localization packs, particularily French?
We're still in the process of certifying and doing release testing on the 9 different languages that we plan on supporting. I'm estimating end of February/early March release.
