I recently attended a class on the problems facing internationalization within software engineering. It brought up a lot of good points that I had never even considered as internationalization problems. Having two internships and having to deal with internationalization problems I had kind of thought that I already knew my way around it and how to effectively deal with the problems. Most of the things I didn’t consider were little logic errors, not larger scale problems. Most notable being that in other languages, what is considered alphabetical, changes. One cannot always assume that if one is looking at a list, that the A’s will necessarily be in a row since the normalization of Á would turn into A but may not be locally recognized as the same.

Many of the problems discussed in the class focused around things that I would consider ‘learnable behavior’. Things such as making sure you are using Unicode encoding, being aware that an icon that has obvious meaning in America may have no meaning at all in another country. GUI design was another hot topic in the class. You have to consider that some language will read right to left rather than left to right. Many languages have words much longer than their English counterpart and could either be cut off in a label or possibly cause a line wrap. All of these things are true and should be the focus of any software engineer that wants to do well with internationalization. However, I believe that this isn’t truly the root cause of the problem. An engineer should be able to pick up simple concepts such as externalizing strings, swapping out icons when necessary, and using a new style of GUI design. I believe that the true problem lies in the environment in which the engineer is developed and kept.

The first true stumbling block of internationalization is the educational system. While in school engineers are only really forced to create programs for themselves that have a very narrow scope of operation. They are never expected to create a program that is to be consumed by any other end user other than themselves, their instructor, and perhaps a grader. The educational system should really take on some responsibility in how they teach students to create deliverables. This wouldn’t necessarily require any sort of major overhaul in the systems. I know that many schools require a sort of capstone class that has a student create a product that, in theory, could be operated by an end user. Since we now live in a world market it would not be outside the scope of a class such as this to incorporate ideas involved in internationalizing software. Some of this burden would be taken off of the educational system though if perhaps development books were written in a new way.

Development books are a cornerstone for the growth and education of any software engineer. The problem in these books however is that more often than not they focus on almost entirely over simplified examples. In introductions to languages this is to be expected and I don’t think that “Hello World” needs to be internationalized in an effort to expose new engineers to internationalization. Exposure should, however, be given soon after the basic concepts of programming are taught. I can’t entirely blame the book manufactures for producing code in this manner though because most current languages are only written in an English readable format.

An English readable format is perhaps one of the largest stumbling blocks that an engineer has to face when creating software that is to be internationalized. If a native English speaker is creating a program, more often than not, that language will read almost like English and will have a sort of familiar flow to it. It really distracts the engineer from the fact that it needs to be internationalized because in the mind of the developer it seems to flow so well. Languages are written in stone and there isn’t really any logical way, or reason, to go back and write C++ and Java so that it is absolutely unreadable to anyone. This does though allow a good metric on which to judge a software engineer and his dedication towards internationalization. If an engineer is able to distance himself enough from his own native language then he is a software engineer who is not only able to create programs that will conform to internationalization but also an engineer that should be seen as willing to push himself and constantly grow. Not all of these problems lie on the educational system and the engineer themselves. A good majority of this responsibility falls on the industry as well.

While an engineer may be put on a one way track through his education, and perhaps books if they study on their own time, industry is often guilty of endorsing such behavior. Once an engineer has finished school and heads into industry, there is usually a short time dedicated to educating that engineer. Most of this education focuses on business-centric education. More and more businesses are moving towards including internationalization education in their training and that is a major first step. Sadly it is only a baby step because once the engineer is in his position, education ceases and practice begins. In many engineering environments, engineers are expected to produce, produce, produce. While I am sure many engineers expected this, and industry loves it, I am pretty confident that it is not what is best for industry. While the industry is expecting engineers to produce they are unintentionally culturally isolating the engineer and, despite what they may think, actually lessening the expectations on engineers. While the expectation of work may have increased, the expectation of continuing education decreases. Many businesses offer incentives to continue education which sounds very appealing. However, when your work expectations are so high, it leaves little time to dedicate to continuing one’s education. If a company wants to see their engineers succeed in an international environment they need to dedicate their time to putting engineers on the front line and truly showing them the problems that are faced on an international stage. Many examples given involve how a GUI interface may mess up, but this is only the beginning of the problems seen in the international space. If an engineer is able to see how his work affects another individual from poor internationalization, it would allow them to have a more real understanding of how what they do directly impacts the global stage.

While many of these problems seem large and insurmountable, they aren’t. All it takes is a shift in the way people think and develop software. Luckily this isn’t a large shift in thinking and only minimal effort on the side of input to see a large change in the output produced by engineers. Until these small problems are addressed though, I feel that the problems seen in internationalization will continue to be an ongoing uphill battle.