Writing globalized speech applications - part I introduction

For those of you who have attempted to write a speech application that works in different cultures and/or languages, you have probably noticed that this is not a straightforward thing to do.  While Speech Server supports applications that run in multiple languages, our tools do not always make this easy.  Another hurdle is that writing globalized speech applications can be much more involved than traditional globalization, requiring more specialized knowledge and solutions to different problems.

Over the next several blogs I will cover a wide range of topics concerning globalization in regards to speech applications.  I do not guarantee that there will be a post every day but I will try to get them out in a reasonable amount of time.  As always, if there are any topics you would like addressed that I do not list please let me know.  The following is a rough outline of what lies in the next posts.

Introduction - How can I make life easier for myself if I may have to globalize later but don't want to now?

Strategies of determining the language - How can you determine what language the user prefers?

Changing the language - Once you know the language, how can you tell MSS to use it?

Localized prompt strings - How can I change my prompts to be in another language?

Prompts + Prompt Validation - How can I use localized recorded prompts in my application?

Grammars - How can I manage my grammars for different languages and what can I do to make my life easier?

Non-Supported languages - If I do not have a synthesizer and recognizer for the language I want to use, do I still have options?

Language mixing - What if I am deploying my application in an area where languages are often mixed - for instance where the spoken language is one language but place names are in a different language?

Regional dialects - How can I improve recognition for applications deployed in an area with a strong dialect or accent?

Handling globalized data - What is the easiest way to handle dates and numbers, which differ depending on the locale of the user?

Culture specific data - How can I handle data that is specific to only one culture without making my application code a mess?  For instance, social security numbers are useful in the United States but not elsewhere.

Tuning globalized applications - How can I pinpoint issues that occur only in one culture?