OK, so you have an application that will be deployed only for three counties in Northeastern Kansas and are quite sure that you will never need to worry about different date formats or languages? Are you positively truly 100% sure about that? What if your application is so successful that your boss wants to package it and sell it elsewhere in the country? What if a new law is passed requiring your application to support Spanish? What if your company is purchased by a German firm that is very impressed by your application?
I am not saying here that every speech application needs to be designed to support Spanish, French, German, and Latvian out of the box. My point of this post is that you can make your life much easier for yourself if you plan globalization into your app now rather than retrofit your application later. If you design your application now to keep open the possibility of globalization or localization, you will find that it only adds a very marginal cost to your work and could save you hundreds of hours in the future. In fact, many of the practices for creating globalized applications are general best practices that should be followed for all applications.
So, if you think that your app will never be globalized, don’t bother reading the rest of this series, but do use the following guidelines in your application.
1) Put everything in resource files. By default, when you create a new project a PromptStrings.resx will be created for you. When you use the Dialog Designer, your strings will be automatically added to the PromptStrings.resx file. But what do you do for dynamic prompts? What you should not do, is place them with your code. You should instead do one of the following.
a) Place them in the PromptStrings.resx file. “But the file says not to do that!”, you might say. Well, for those of you who did it anyway you probably noticed that your application still works. True, this is not the best place for them but any string here will still be found by prompt validation, making it easier to add these strings to the prompt database.
b) Add your own .resx file. There is no law stating that you can only have one .resx file in your project. When you add your own .resx file in Visual Studio, VS will automatically add a resources.cs file to make it easier to retrieve these resources in your code.
2) Don’t just place strings in resource files. Anything that will differ in another country or language should be placed in a .resx file. Some people might scratch their heads a bit about what that might be – but think… What else in a speech application will differ in another language?…. The grammars! Of course, you do not need to (nor would I recommend) placing the entire contents of the grammar in the resource file. You just need to place the name of the grammar in the .resx file. That way, if you add another language you just need to change the grammar name in the .resx file for that language and you have no need for adding if statements wherever you load a grammar. Wav files also fall in this category.
3) Don’t always assume dates and numbers are in the EN-US format. Of course, if this is done in the grammar it is quite difficult to avoid – but that’s why we localized the paths to the grammars. If you are parsing in code though, try to use one of the .Parse methods in .NET rather than rolling your own.
4) Design and cut. Basically if you are going to write an application that only runs in English, write a specification for one that supports both English and Spanish and then cut Spanish support. That way, you will be forced to create the infrastructure for an application that can support multiple languages but you will not need to add the actual Spanish data. I have gone through far too many teams that have globalization as an after thought and have witnessed companies waste millions of dollars that they could have saved by just planning for localization in the first place.
In summary, and I know I might sound extreme in this but those of you would have had to localize or globalize applications that weren’t designed up front for it will know, there is no such thing as a good non-localizable/non-globalizable application. Every successful application will have to be globalized and localized at some point given the global nature of today’s economy and within our own country. Plan for this up front and you will save yourself a world of hurt later. If you are presenting costing to your boss for an application that is shipping in only one language, I would not even include this as a bullet – “Support for future localization/globalization”. The vast majority of the managers in the world will read this as “Cut this item to shorten the time to ship”. Do you cost the time to initialize variables and write for loops? No, as you should not cost the necessary work to make sure that you create an application that is easy to modify to adapt to different languages and cultures.
If you do not heed this advice, then be prepared some day in the very near future to be very frustrated as you spend your time reworking your product because someone in marketing decided to enter the Japanese market and you are rewriting mundane code while your competitors and friends in smarter companies are adding new and exciting features.