How much work has been done (or thought given to) globalizing the codebase, and ensuring the localizability of the code?
I do think a culture and language neutral codebase would be a far better situation for future maintainability and extensibility than having multiple versions out there for all sorts of reasons/agendas.
With a culture/language neutral version, the addition of new languages or interfaces would become a relatively simple process, and would not put at risk the stability of the existing code.
Of course, I haven't seen the existing code-base, so I don't know how big a job this would be, but I'm assuming multi-language support wasn't an original design consideration, so the separation of resources from code is not likely to be an easy job, however the longer you leave it, the more difficult this task becomes.
I'm not in a position at present to suggest whether this should be done or not, but I'm just suggesting that perhaps the pros and cons should be considered and discussed by the people involved in coding. I'd be interested to hear your opinions.
As background, here's some of what MSDN has to say on this subject:
Planning World-Ready Applications
Your first step in the process of developing a world-ready application is globalization. A globalized application can correctly accept, process, and display a worldwide assortment of scripts, data formats, and languages. However, while your globalized application may possess such flexibility, the language of the user interface remains unchanged. That is, you have not localized the application for another culture/locale.
An intermediate step prior to localization is a process known as localizability. Localizability is about ensuring you have enabled a globalized application for localization by separating the resources requiring localization from the rest of the application. Proper localizability results in source code you will not have to modify during localization.
The final step, localization, is the process of customizing your application for a given culture/locale. Localization consists primarily of translating the user interface.
If you address globalization, localizability, and localization requirements during the design phase, you will maximize the quality of the localized applications and minimize the amount of required time and money. On the other hand, retrofitting existing applications for localization typically results in inferior localized versions, increased cost, and increased time to market.
Localizability
In the past, the term localization often referred to a process that began after an application developer compiled the source files in the original language. Another team then began the process of reworking the source files for use in another language. The original language, for example, might be English, and the second language might be German. That approach, however, is prohibitively expensive and results in inconsistencies among versions. It has even caused some customers to purchase the original-language version instead of waiting months for the localized version. A more cost effective and functional model divides the process of developing world-ready applications into three distinct parts, globalization, localizability, and localization.
The primary advantages of designing and implementing your application to be sensitive and appropriate to regional conventions, data in a variety of world languages, and alternate format are:
You can launch your application onto the market more rapidly. No additional development is necessary to localize an application once the initial version is complete.
You use resources more efficiently. Implementing world-readiness as part of the original development process requires fewer development and testing resources than if you add the support after the initial development work starts. Furthermore, if you add world-readiness to your finished application, you might make it less stable, compounding problems that you could have resolved earlier.
Your application is easier to maintain. If you build the localized version of your application from the same set of sources as the original version, only isolated modules need localization. Consequently, it is easier and less expensive to maintain code while including world-readiness. The key to this aspect of designing software rests in using resource files for the localized versions of the application.
