I started learning programming around the age of 10 or 11 by following a silly column in a newspaper where once a week they showed a small BASIC program. I did not have a computer, so I basically wrote program state at each point in a box on a piece of paper. One day, one of my mom's co-workers sat me in front of a VAX terminal and let me type things. I kept getting error messages, but I was hooked. My mother and my great aunt organized the smuggling of a ZX Spectrum 48K from Germany to Turkey for me and my brother.
Given that the computer had been purchased in Germany, its instruction manual was also in German, and trying to learn BASIC using my rudimentary understanding of German was proving too frustrating. One day, I found Mastering Machine Code on Your ZX Spectrum. Until then, I had been typing up listings from various computer magazines, trying to figure out how things were working (remember, no internet then. In Turkey, even inter-city calling used to take hours sometimes). I bought that book. Didn't have anything other than simit for lunch for a few days, but it was worth it.
What I learned in that book changed my life. The CPU, RAM, ROM, interrupt tables … Later, my Spectrum 128 II helped me learn about paging memory in and out. But, it all started with Toni Parker's fabulous book.
Over time, some books in Turkish started appearing on bookshelves. Invariably, those books were disappointing because of an imperfect correspondence between the words they used for various English language terms. Take, for example, the term interrupt handler. METU's dictionary gives the translation as
iş kesme kotarıcı. If one is not already familiar with the concept of an interrupt handler and also with the various twisty positions people get themselves into while trying to translate computing terms, one would have no idea what that term represents. That is, the phrase
iş kesme kotarıcı is just as meaningless to a Turk as is the phrase interrupt handler if she is not already familiar with the concept.
However, if she is never exposed to the English phrase, but only learns in various Franken-translations that vaguely sound Turkish, she won't be able to communicate with people who did not learn the concept using the same Franken-translations. Sure, you can say, first learn using Franken-Turkish, then learn the English terms. But, why double the work?
The same goes for translation of software menus. I know it is very fashionable right now, but it is also very counterproductive on international teams. Even simple terms like record format are problematic. The same METU dictionary gives the translation as
tutanak formatı where the word
tutanak literally means meeting minutes. That makes absolutely no sense, and makes it impossible to transfer skills learned on the Turkish version of a piece of software to the English version.
The upshot of this is to make programmers and other workers who learn using Franken-translations less easily substitutable in place of programmers and other workers who learn using the English version. After all, English is still the easiest to learn lowest common denominator language. Plus, most of the related knowledge is available in English. Most of the terms in common use started in English dominated software. Whether you think this is good or bad, it is the way it is. And, if people working with software need their knowledge to be portable, they need to know the English terms for everything they use.
There is nothing that annoys me more than trying to help family and friends with computer stuff, only to find them running Turkish versions of software. Most shortcuts are different (but never all), most menus are ordered differently, mnemonics are not the same etc. It makes me realize that had I been introduced to computers and related concepts only in what people thought were correct translations, my progress later would have been much slower.
This is different than software working equally well regardless of the language in which the content is written. I am all for that. However, learning programming concepts and software tools in another language than English doesn't help. In most cases, it serves to prevent programmers and other workers in poorer countries from competing with rich programmers in rich countries.
Now, if you are in the business of selling programming books, and your potential consumers don't think that they are putting themselves at a disadvantage by reading the translation, rather than the English version, then, by all means, give them what they want if the revenue from doing so exceeds the cost. That's a business decision. I am only remarking on the effects I observe.
Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it.