From the experience of translating style guides
Hello, dear habrozhiteli! I would like to bring to your attention the experience of translating the well-known code design style guide among Ruby developers. The original text of this manual is compiled by the community of Ruby programmers under the creative direction of Bozhidar Batsov .
For many of you, it may seem that translating an English-language programming resource is a thankless waste of time, because most developers speak English. We, however, had a fairly clear motivation: to thoroughly familiarize ourselves with the well-established practitioners of the Ruby code design. And in the process of translation it is necessary to read the text twice, if not three times.
In addition to this purely mercantile basis, we believed that the development of terminology would simplify technical communication in the native language (the question “why?” Is a simple answer “because!”), And also makes it possible for those who find it easier to read this resource. in Russian.
The initial translation was made in a copy (fork) of the main project on Github, after that, as changes in the base (upstream) version were accumulated, revisions were made on a regular basis. In this process there are several noteworthy points:
')
* Changes from the base version are transferred using diff and patch , since the structure of both projects is somewhat different:
* it is more convenient to view the changes in the English version as a difference before and after merging with the basic version:
Using graphical tools like meld makes comparison easier thanks to color highlighting.
The main difficulty (however, as in any similar translation project) is the translation of terminology and its maintenance in a uniform state. The scope of the project allows to do without translation memory systems and to keep a simple glossary. Unfortunately, in many matters there is still no settled option. Search for translated subject literature and discussion with project participants is a sensible solution in this case.
If you want to participate, then join the project ! We will welcome any constructive criticism.
For many of you, it may seem that translating an English-language programming resource is a thankless waste of time, because most developers speak English. We, however, had a fairly clear motivation: to thoroughly familiarize ourselves with the well-established practitioners of the Ruby code design. And in the process of translation it is necessary to read the text twice, if not three times.
In addition to this purely mercantile basis, we believed that the development of terminology would simplify technical communication in the native language (the question “why?” Is a simple answer “because!”), And also makes it possible for those who find it easier to read this resource. in Russian.
The initial translation was made in a copy (fork) of the main project on Github, after that, as changes in the base (upstream) version were accumulated, revisions were made on a regular basis. In this process there are several noteworthy points:
')
* Changes from the base version are transferred using diff and patch , since the structure of both projects is somewhat different:
$ git fetch bbatsov $ git diff master:README-enUS.md bbatsov/master:README.md > patch.diff $ patch README-enUS.md patch.diff * it is more convenient to view the changes in the English version as a difference before and after merging with the basic version:
$ git difftool master@{1} master -t meld Using graphical tools like meld makes comparison easier thanks to color highlighting.
The main difficulty (however, as in any similar translation project) is the translation of terminology and its maintenance in a uniform state. The scope of the project allows to do without translation memory systems and to keep a simple glossary. Unfortunately, in many matters there is still no settled option. Search for translated subject literature and discussion with project participants is a sensible solution in this case.
If you want to participate, then join the project ! We will welcome any constructive criticism.
Source: https://habr.com/ru/post/245419/
All Articles