You know, as a professional software developer it is very easy to see your code used by an international audience. My latest commercial effort GTS currently does not have any users outside of North America, but it is our intent to see this product in use around the globe. This morning I was reading an article on The Guardian Unlimited website that discusses the trials and tribulations that Microsoft has gone through when distributing software to a global audience.
If Microsoft, arguably the world's most powerful software company, struggles with getting internationalization right, then what hope is there for my company? Yes, we architect's GTS from the ground-up with an international audience in mind. As GTS is a VB product, this means that we built all of the content display (words, captions, etc.) to work from resource files which are a better-than-nothing solution. I say this because resource files are an imperfect solution, since the expectation is that all languages are generally about the same size when it comes to the verbosity of meaning. Resource files simply provide the same content in different languages, so one command button may say 'Exit' in English but 'Sortie' in French. Mind you, there is only a 2 character difference between the words, but this is a 50% larger size than the English version. It really hasn't caused us a problem with single words (yet), but when it comes to having more than a few words and bam you get slapped by the 'gotcha'.
The real problem here is the fact that resource files were meant to be a way to keep a SINGLE source code set to produce multiple language versions. The reality is that you sometimes HAVE to fork your code to accommodate layout changes necessitated by one language. Some of you may be saying that this isn't necessary, as we could simply make the whole app fit the largest common denominator, but this involves other pain - mostly with our established customer base.
When you go about making wholesale changes to any layout or interface, it takes people time to adjust to the new location of the presentation contents. This is change, and most people really don't like change, especially when it isn't really necessary (as far as they can see) . The question comes down to who should have to change, who is it that will bear the brunt of the work to change; me the small software development company owner, or the myriad of users of my product?
Well, the real power here exists not with the guy at the programming keyboard, but rather it exists with our customers. GTS is in a very competitive market, and while it is doing well and expanding its horizons, our customers and potential customers have other choices. If we abuse them or lead them to feel that we don't really consider them above all else, they can easily walk away from our relationship. Yes the programmer makes the content of the application, but it really is the user who controls what is there.
All this verbage is a way to help you understand the difficult decision that we face at SinglePOINT as we expand to wider audiences (even within Canada, we need to fully support French, as our Quebec and New Brunswick markets expect it). In the end, I vote that we do NOT fork our code base, as this can effectively double our effort (or quadruple++ it) with every forking. I know that to put our users through change isn't great, but I hope that when they do upgrade to the next version of GTS, that any changes to the user interface layout are delivered with a good balance of improved performance, features and usability.
In the end, if we can spend more time improving GTS while we also shuffle its look and feel to accomodate an international audience, I believe that our customers will accept the pain for the gain.
