If you think that your application may be used internationally, it has to work with any choice of Windows Regional Setting, on any language version of Windows, and with any language choice for the Excel user interface.
If you are very lucky, all your potential users will have exactly the same settings as your development machine and you won't need to worry about international issues. However, a more likely scenario is that you will not even know who all your users are going to be, let alone where in the world they will live or the settings they will use.
Any bugs in your application that arise from the disregarding or ignoring of international issues will not occur on your development machine unless you explicitly test for them. However, they will be found immediately by your clients.
The combination of Regional Settings and Excel language is called the user's locale, and the aim of this chapter is to show you how to write locale-independent VBA applications. To do this, we include an explanation of the features in Excel that deal with locale-related issues, and highlight areas within Excel where locale support is absent or limited. Workarounds are provided for most of these limitations, but some are so problematic that the only solution is to not use the feature at all.
The rules provided in this chapter should be included in your coding standards and used by you and your colleagues. It is easy to write locale-independent code from scratch; it is much more difficult to make existing code compatible with the many different locales in the world today.
Was this article helpful?