nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Language &quot;swapping&quot; within the application,

AdamDrackley1

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.

Find more posts tagged with

Accepted answers

DerekLaw

Hi Adam,

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.

Hope this helps,

All comments

DerekLaw

Hi Adam,

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.

Hope this helps,

AdamDrackley1

Just because someone has to ask; Any dates on release for the localization packs, particularily French?

AdamDrackley1

This is a great answer. Many thanks.

DerekLaw

Hi Adam,

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.

Hope this helps,

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.