In this piece, I’d like to have a quick look at the book-based learning in 2017 and why it’s a good idea to always reach out for the original pieces rather than localizations, even if it does require a bit of a stretch.

I’ve spent several years working on technical translations in various fields, including IT. In general, the content is sent to translation/localization for one main reason. The idea of expanding and reaching the new audience. However, the situation with the handbooks, especially in IT doesn’t quite fall into this category. In a few steps, I’ll try to convince you why it’s much better to reach for the books written originally in English.

Publishing delay

Today, IT is probably one of the most dynamic industries out there. I bet the brave one, who comes to grips with JavaScript in 2017 would agree wholeheartedly. New tools seem to arise every week, new builds and trends show up just to disappear a few moments after (bye bye Bower!). The trend seems to reach its peak in web-development, however, it’s not the only case.

The thing is that publishing houses don’t work this way. Firstly, a new handbook is published in its original language. Then, if it gets a positive reception, other houses dive into the details of publishing rights’ transfer negotiations. After the deal is signed, a team of translators is gathered, leading translator creates the documentation, the content is divided among the team (which is often the cause of even more misunderstanding, we’ll talk about that later), and finally, hopefully after proofreading, the book gets published locally. The process usually takes between 1-2 years, sometimes a bit less, if the negotiations take place in parallel before the original book gets published.

Let’s be honest, two years in an environment like development is a lot. This usually means that some of the content is already obsolete after it reaches the customer in the first place.


A chessboard like this was given as an example in one of the PHP books of major Polish publisher. The first letters of figures in code sample were translated, however, the image remained unchanged, what might cause confusion.

A chessboard like this was given as an example in one of the PHP books of major Polish publisher. The first letters of figures in code sample were translated, however the image remained unchanged, what might cause confusion.

Translating a book is like creating an additional layer between the original and the viewer. Seldomly, the translations may add value to the reader, but more often mistakes of dual nature come up. First one derives from the division of content among the team. A low quality, imprecise technical specification can cause the book to have different localized terms describing the very same archetype. If you’re an experienced developer, this won’t cause you much trouble, because chances are you’ve already structured most of the content in your head. However, if you’re just starting, it can possibly derail you and send you drifting, while trying to connect the blurred, mislabelled dots. 

The second type of mistakes is caused by cost-cutting the project and not hiring the right people for the job. The golden rule is industry specific books shouldn’t be localized by generic translators. As an outcome, the content will just not “sound right” in terms of industrial jargon. Hiring the right man for the job of localizing a book about the SQL performance quirks won’t be easy, nor inexpensive. As a result, you may end up with a book containing strategies which may cause unpredictable collateral damage to the database.

Language of the web

Captain Obvious used to say that English is the language of the web, thus even if your language is far from perfect, it’s worth it to stretch out and reach for the handbooks in their original form. It’ll take you more time, but improving both your vocabulary as well as an industry-specific skillset is worth it. It will pay off while trying to find the answer to your problem on stack, reading other developers’ comments and analyzing classes’ structures.

The bright side

When it’s worth to put your hands on the paperback in your local version? Two cases:

  • the book was originally written in that language by a specialist in his/hers field
  • content of the book is a part of a universal, cross-language knowledge base such as algorithms, design patterns, code clarity, working with client etc.


There are currently no comments.

This site uses Akismet to reduce spam. Learn how your comment data is processed.