Should source-code in textbooks and the like be translated?

Question

A few weeks ago, my class was assigned to translate to Portuguese the book Real World Haskell. As I did the translation of the text and comments, I started to wonder if I should translate the code as well, as the instructor suggested. For example:

data BookInfo = Book Int String [String]
              deriving Show

would become

data InfoLivro = Livro Int String [String]
               deriving Show

Since I haven't read any software-related books in Portuguese, I don't know if that's a common practice, neither if it should be done this way. In the end, the code is a language mix (perhaps the example in Haskell is not a good one, since you can create synonyms quickly like type CadeiaDeCaracteres = String, but you get the point). So it doesn't really matter how hard you try, you'll have to rely on the reader previous experience with some sort of basic English words.

Knowing this, I really don't see the point in translating code, since we learn in the early days of our coding life it should be written in the universal language. Nevertheless, if the surrounding text (comments, for example, and text itself in a book) needs to be translated, what is possible and feasible in this matter? Can you provide me with some guidance of what to do?

Answer 1

In my opinion, no. Most programmers are forced whether they want it or not, to learn english, and nowadays it is the lingua franca of the software world.

In my experience, however, books written by authors in one of the stronger languages, have a tendency to do that - so far I've seen the practice in books in german, french and russian (well, russian is a little different of a case, since they use different alphabet as well). It is a rule of thumb that it depends on the country's dependency on english.

The text is of course translated, the bigger comments also (one that describe the workings of a program in greater detail), then somewhat more rare, smaller comments and variable names. I've also seen the case where variable names were translated, but smaller comments were left in english. I believe the author however, in that particular case, was counting on his audience to have a working english knowledge.

Sorry if this didn't solve your dilemma, but there still isn't a consensus on this one :-/

Answer 2

I'm brazilian [we speak portuguese here, ofc] and, when I can choose between the original or the translated version, I always take the original, since almost every book is translated to people who aren't programmers so commands and expressions lose their original meaning after the translation.

Another reason to want books in english is that everything on web [or the best things, like this site] is written in english, so you will be familiarized with the english term and you will be able to understand better other people code... [since a good programmer would code in english, at least from my POV]

If you need to read books in portuguese [or another language] prefer those written on that language [not translated].

To make it clear: if you are going to translate that book, try to keep all code in english [comments may be translated, but not vars or funcs] and don't try to translate stuff like 'array' to 'arranjo' or 'mouse' to 'rato' [at least I would prefer the english term, people on Portugal would prefer the second, I guess].

Answer 3

A good point against translating code examples is this that, if you do, you will have to test them, since the translated code examples are expected to be correct just as the original ones.

Is the testing effort included in the cost of translation? I guess not, in most cases.

If you don't test the translated code, you are risking the code to break or be incorrect, damaging the reputation of both the translated material and the original one.

If you don't want to incur in the effort of testing the code examples, you should only translate comments but not change the code in any way.

Another thing to consider is the fact that the original author most probably had a code base, perhaps a complete app or library that compiles as a whole. The code examples are extracted from such a code base and spread throughout the book. You will not have that, so you could, after translating the code examples, end up with code examples that, in the translated book, contradict each other, due to different translation decisions in different parts of the book, whereas in the original book they don't because they were extracted from the same code base.

Answer 4

As a non-native English speaker, I don't like translated code.

1. Builds good practice. As a professional, not only English is the main language of the field, but people with different backgrounds share and work on the same code. Writing you code in another language greatly reduces the number of people who can work with your code - I had some fun with some code written in another language and it's awful. So, why not encourage good habits?

2. It looks ugly. Most programming languages use keywords in English, and, with a good choice for identifiers, reading a program can be a experience close to the natural language. Unless you use another language for identifiers, which makes it similar to reading in 2 languages at the same time.

3. I don't believe it helps that much. Even for a non-English speaking person, the English used for identifiers in a regular program is quite simple and can be learned very fast.

Answer 5

I don't speak any language other than English. (Well, I Latin in high school. Useful if I ever visit Latin America. :-) With that background, I'd say:

As others have noted, a lot of information about programming, on the web and in books, is in English, so it would certainly help if you learn English.

Some computer languages use a lot of English words, like Visual Basic, for example. Others use mostly symbols, like C/C++/C#. So if you're going to program, you're going to have to learn SOME English. But I don't think it's a lot. IF, WHILE, RETURN, etc. Depending on the language, maybe 10 or 20 words to a few dozen. Visual Basic is the wordiest language I can think of, and I just checked a list and it has, by a quick count, about 160 reserved words, but there's a lot of duplication in there. Like END and WHILE and then END WHILE listed as three separate "words". I can see that being inconvenient for a non-English speaker, but these words are often used with meanings only loosely related to their common English meanings, so I think in many cases it's not that much harder for a non-English speaker than for an English speaker. Like, the meaning of HANDLER or CAST is probably no more obvious to a new programmer who speaks English than to a new programmer who speaks Portuguese. If instead some of these things were called by words that are meaningless in English, like if instead of saying CAST we said FOOBAR, would that have made it harder for me to learn programming? I doubt it would have made much difference.

You mention that some languages have options to define alternate words for keywords in one way or another. So yes, you could define words from your own language as synonyms for the English keywords. I wouldn't. Now your programs have a bunch of non-standard terms that you made up. Someone else who tries the same thing is unlikely to use exactly the same set of words that you do. So now reading someone else's program, you've got to figure out what he meant by his "translations". I suppose if everyone in the company used the same set, you would learn them and could work on each other's programs easily. But what happens when you move to another company, or download software off the web? It seems to me that you're just setting a trap for yourself. Better to just learn the standard words.

If you're writing a program in Portuguese and the only people who are likely to read it are other Brazilians, and you all presumably speak Portuguese but maybe are not particularly fluent in English, it just makes sense to make variable names Portuguese. I don't see what's gained by trying to make variable names in a language you are not particularly good at.