The splendor and poverty of translated literature
“It's better not to read at all than that.”
Do you often read technical literature? It is literature, and not manuals on the hub or bug reports on the github? And when you read, in what language do you prefer to do this (if you can choose, of course)? Which version do you prefer, Russian-language or English-language original?
In some circles, there is an opinion that snobbish and elitist that reading (watching a movie, playing games) is only in the language of Shakespeare and nothing else. For many others, it’s quite difficult to check the first on the topic of whether they are simply arrogant or whether there are any serious problems with the translated technical literature. Trite because of poor language skills in the original.
Another complication is added by the area of knowledge around which this all happens. It is often not easy to recognize the border where a misunderstanding of complex data structures or new development methodologies themselves goes into a misunderstanding of the text that the translator composed. Here, for example, is a quote from a fairly recent book:
In high school, he began creating dynamic websites when the Internet was still relatively young. He then went on to develop software for the healthcare and telecommunications industry at a local company, studying computer science at the University of Ljubljana, Slovenia. In the end, he went on to work at Red Hat, initially developing the open source implementation of the Google App Engine API, which used mid-tier Red Hat JBoss products. He also worked or participated in projects such as CDI / Weld, Infinispan / Jboss DataGrid, etc.
Since the end of 2014, he has been part of the Red Hat Cloud Enablement team, where his responsibilities include updating new developments in Kubernetes and related technologies and maximizing the potential of Kubernetes and OpenShift in mid-tier software.
If you haven’t gotten sick from the passage “initially developing an open source implementation of the Google App Engine API”, then you probably have questions about what kind of “mid-level company” suddenly came up. Or what, for example, means "updating new developments." Turn to the original text:
Since late 2014, he has been part of Red Hat's Cloud Enablement team, where his responsibilities include staying up-to-date on new developments in Kubernetes and related technologies and ensuring the company middleware software utilizes the features of Kubernetes and OpenShift to their full potential .
It turns out, in fact, this is not a mid-level company. And we are talking about the middleware of the company. And no one forced him to “update new developments” - in fact, he needs to be constantly in the know about all new developments.
Or another example, from another book:
In 2007, I contacted Yahoo executives about a position that related to “a bit of development” and “a bit of exploitation”. It was about the vacancy of a senior service engineer responsible for creating and maintaining a multi-tenanted, hosted, distributed and geographically replicated key / value data warehouse called Sherpa.
“A multi-tenanted, hosted, distributed and geographically replicated data warehouse” - you can immediately understand what exactly this mess is, or you will have to first translate it back to English to realize which familiar terms were so glamorously localized to the great and mighty?
Does this help simple learning? Honestly, not really. Do you want to spend considerable, in general, money on a dense linguistic jungle, in the depths of which there is a hut with treasured clay tablets? Do not want. I would like for another: to have access to a set of simple and understandable texts, the most difficult part of which would be the ideas presented by the author, and not strange language constructs built by the translator.
Trying to figure out why it happened
How did it happen? Has it always been like this? Can we somehow avoid such incidents in the future? I would suggest leaving questions of a low level of language competence outside the scope of this discussion, because we can’t directly influence it directly. There are just good translators, but not very good ones. Like programmers. And the dentists. And in general, anyone.
But what additional difficulties do bilinguals even seriously savvy in both languages encounter when they decide to start translating IT literature? Information technology over the past 10-15 years has grown tremendously, both horizontally and vertically. A huge number of new professions, each with its own specialization. Owing to the linguistic inertia of human perception, many related professions use the same terms, which, however, carry different meanings. And in order to understand how to properly use and translate a particular term, you need not only good command of the language, but also a good understanding of a specific area and subsections of the information industry.
Roughly speaking, at the same time as the universal form of the “programmer” (which to raise the server and write the script, and the conder in the motherboard to re-solder) ceased to exist, the universal “technical translator” ceased to exist. Therefore, now it’s not enough to be “just a translator”. It would be nice to be, first of all, a technical specialist who, as an addition, is fluent in languages. And this, as you know, is a completely different story. Not all good technical specialists have sufficient language skills. And if they do, it is far from always interesting for them to engage in this kind of work - they are more attracted to technical achievements than humanitarian ones.
“And before, before, how good it was!” (from)
The methodology of “translating” new words is now widespread by simply substituting the existing Englishism. For example, commit (more or less normal translation “fixation” is already almost everywhere crowded out), build, deploy - the list can be kept endlessly. Most likely, this situation has developed due to the accelerated pace of the emergence of new technologies. The translation, like any other reactive system, simply cannot keep up with the given pace. And by the time when any text reached the translation by professionals, techies had already formed deeply rooted jargon - and the translation of the term “commit” with the word “fixation” would hurt the reader’s eye.
But this does not mean at all that one must put up with a similar situation! There are excellent examples of high-quality, well-thought-out translation. From the examples we can take “thread” - “thread”. The literal translation - “thread” - suggests that, most likely, at the dawn of the formation of English terminology, it was an association with a loom with a bunch of parallel-stretched threads. In the Russian language, “multi-thread execution” sounds very incomprehensible, but “multi-thread execution” is a completely different matter. Here the semantics are preserved, because the flow is a constant movement (calculation), which the thread does not have. And it sounds quite familiar (“cars move in several streams along the freeway”).
Another example of a well-localized term is “pipeline” = “pipeline”. “Pipeline” is a pipeline, the essence of the term (rendering pipeline, CI / CD pipeline) is the processing process, where some action takes place on each node: depending on the conditions, “valves” can be closed and opened and processing proceeds through another “ the pipe. " Throughout the entire pipeline, some kind of “sensors” can be placed that monitor the process. The word was chosen very well, but the direct translation, "rendering pipeline" does not sound concise enough. “Conveyor” in this case is a perfectly matched word, except with a different shade (convey — convey, but “flows by itself” through pipes), but without losing the main meaning.
How to live further?
What do we offer for our part? We offer the very unique fusion of technical competencies with quality language skills. We are ready to devote time to our technical specialists to bring the semantic content of translated texts to perfect condition.
In the process of working on translations, we have to spend a lot of time in discussions on the topic of how to localize certain terms. In this regard, it would be nice to start compiling a common glossary of new terminology, for subsequent use in both our own translations and translations of our colleagues. This glossary should not be just a collection of words; First of all, it is called upon to explain why such a term was chosen, why it is better than similar ones, how it fits into the language context - well, and our technical tradition. Without blind and thoughtless tracing of foreign terminology.
This is the glossary we plan to do. For starters, apparently, this will be a series of articles with an overview of collections of terms, the history of their appearance and development, as well as the objects behind them. Subsequently in each bookour publisher will have a separate section describing how we worked on the terminology used in this book. As the material is recruited, a separate publication is likely to be issued on the problems of the Russian language in modern information technology translation. In the meantime, you can pre-order our first book, “Designing Event-Oriented Systems,” by Ben Stopford.
And what thoughts do you have about the situation in the translated technical literature? Are there any terms that are especially dear to the heart, which, in your opinion, were perfectly translated into Russian? Or maybe there are especially hated ones? :)