alextretyak/7.en.pq.txt

## 7.en.pq.txt
[[[
[[[Хабы: Локализация продуктов, Мозг]]]
[[[Header: A new writing method/technology (“dendrowriting”), as exemplified by the YearVer site]]]
[[[Tags: dendrowriting, dendrotext, yearver, bilingual article, двуязычная статья]]]
]]]
Several years have passed since the appearance of ‘the first text markup language that supports “dendrowriting”’[https://pqmarkup.org], but no worthwhile piece of text demonstrating the advantages of the new writing method/technology has yet appeared.

The largest “dendrotext” was a couple of paragraphs in the ‘pqmarkup documentation’[http://pqmarkup.org/ru/syntax ‘‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’’], consisting of only ~1300 characters and available only in Russian.

In English there was no “dendrotext” at all, as such [apart from small insertions in the documentation for the 11l programming language (e.g., ‘Boolean type’ in ‘Built-in types’[http://11l-lang.org/doc/built-in-types])].

But [[[this/]]]last year...
'‘<cut />’'
... when I was tidying up the meta-information[‘specifically the version numbers and status [Beta/Stable]’] for my projects, I noticed that I had settled on recording version numbers in `YYYY.M[.n]` form. Then I got the idea of giving this designation a name: YearVer [obviously, by analogy with SemVer]. And the rule for naming additional versions {published in the same month or fixing bugs in the main version} formed the basis of the text for a new website.

Soon after, I learned about the existence of CalVer from the ‘Software versioning page on Wikipedia’[https://en.wikipedia.org/wiki/Software_versioning]. This disappointed me a little, but when I took a closer look I found out that calver.org[https://calver.org] does not give any specific recommendations about which “calendar versioning” scheme should be used, but simply describes the schemes already used in various projects, without highlighting them in any way.
The creation of a site for YearVer thus remained relevant, and I continued to fill it with content.

The resulting description of the YearVer versioning scheme turned out to be quite short and concise, but very definite, offering specific schemes/strategies depending on the type of project.

And the most challenging task was now to translate the yearver.org/ru page into English, preserving the formatting.

To obtain a high-quality translation, I decided to contact three different translation agencies at once and to emphasize the fact that I was interested in maximum quality and ‘prepared to pay extra’[‘for the sake of fairness I should say it was only the second and third translation agencies I told I was prepared to pay extra for quality; in my message to Alconost I just indicated that ‘I need a very small text translated, but to a very high quality’’] for it.
I contacted:
. Alconost (it was the first link in Google search results for ‘бюро переводов сайтов’\‘website translation agency’)
. transly.ru and tran.su (found by searching for ‘бюро переводов markdown’\‘translation agency markdown’)

In the process of communicating with the first translation agency, the rules for reading “dendrotext” were formulated:
1. Hidden text 0‘{...}’ should be expanded only after the [corresponding] paragraph has been read in its entirety.
2.‘Hidden text 0‘{{...}}’ should be expanded after 0‘{...}’.

For example, in the following sentence [from [http://yearver.org]]:
> Additional versions published in the same month, or 0‘{…}’ those fixing bugs of the main version 0‘{…}’, shall be numbered `2021.2.1`, `2021.2.2`, and so on.
the second block of hidden text should be expanded (after the words ‘main version’), then all its nested blocks, and only then the first block (after the word ‘or’).
‘Why was this “dendrotext” organized this way?’{
‘(Before reading this explanation, I strongly recommend that you read [in accordance with these rules] the indicated sentence from yearver.org in full)’{
The second block of hidden text (after the words ‘those fixing bugs of the main version’) introduces the concept of bug-free projects, clarifying that such projects do not need bug-fixing versions. [And its [second block] could actually be placed right after the words ‘fixing bugs’ [{but I did not do that, since the first and second blocks of hidden text would then be too close to each other}].]
And the first block of the hidden text relates to the word ‘or’ (therefore it is located immediately after it), but since it uses the concept of bug-free projects [introduced in the second block], it should be expanded after the second block [which is why the first block was enclosed in additional curly braces].
}
}’

At the end [of the translation process] there remained the painstaking work of “merging” the three translations I received into one text, choosing the best translation variants for each sentence and each term/concept.

‘Why “dendrowriting”?’{~‘Dendro-’ comes[https://www.dictionary.com/browse/dendro- <- google:‘dendro dictionary meaning’] from the Greek ~‘déndron’, meaning “tree”. However, if you think of a tree as a data structure [in programming], then it's really not very clear how “dendrowriting” relates to it. But if you take a look at ordinary/real trees... Try to draw a vertical line on a piece of paper: that's the trunk of the tree, and this is your text [a paragraph or just a sentence]. Now go from bottom to top, and once you reach the first block of hidden text, make a branch (to the left or to the right {you can alternate: the first block of hidden text branches to the left, the second to the right, the third to the left again, etc.}). Then you expand the first block of hidden text [bottom branch of the tree]. It can either consist of plain text or contain other blocks of hidden text corresponding to the sub-branches of the tree.[[[In principle, a classic spoiler can also be considered a form of “dendrowriting”.]]]

‘And how is it different from classic spoilers (like this)?’{
“Dendrowriting” is blocks of hidden text within a paragraph.
Whereas the classic spoiler is a separate paragraph in itself {but which, like a block of hidden text in “dendrowriting”, may contain multiple paragraphs}.
}
[[[
> What is the difference between “dendrowriting” and “dendrotext”?
< “Dendrowriting” is a writing technology, and “dendrotext” is a text written using that technology.
]]]}

'‘’'

## 7.pq.txt
[[[
[[[Хабы: Локализация продуктов, Мозг[[[https://habr.com/ru/post/542534/ <- https://habr.com/ru/post/548004/ <- https://habr.com/ru/top/]]]]]]
[[[Заголовок: Новая технология письменности («древопись») на примере сайта YearVer]]]
[[[Метки: древопись, древотекст, yearver, двуязычная статья, bilingual article]]]
]]]
Со времени появления ‘первого языка разметки текста, который поддерживает «древопись»’[https://habr.com/ru/post/348218/], прошло вот уже несколько лет, однако достойного текста[[[а текст на странице [http://yearver.org/ru] достойный? ну не то, чтобы в полной мере достойный, но уже кое-что]]], демонстрирующего преимущества [[[нового вида/]]]новой технологии письменности, так и не появилось.

И самым большим «древотекстом» была пара абзацев из ‘документации к пк-разметке’[http://pqmarkup.org/ru/syntax] {‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’}, которые составляют всего ~1300 знаков.

А на английском языке «древотекста» как такового не было вообще [не считая [[[крошечные/]]]маленькие вставки в документации к языку программирования 11l (например ‘Boolean type’ в ‘Built-in types’[http://11l-lang.org/doc/built-in-types])[[[, в которых, по правде говоря, применение «древописи» не является так уж необходимым {можно было обойтись классическим спойлером}, а скорее сделано «для галочки»]]]].

Но в [[[этом/]]]прошлом году...
'‘<cut />’'
...когда я приводил в порядок мета-информацию[‘в частности, номера версий, а также статус [Beta/Stable]’] своих проектов[[[{
А именно:
. pqmarkup[https://sourceforge.net/p/pqmarkup/code/ci/8bc599060a78bb1a85a29206ef16f48d1a07a129/]
. ELDF (1[https://sourceforge.net/p/eldf/code/ci/5448665c6266eb334d47a4c20b8861202f52d329/#diff-4] и 2[https://sourceforge.net/p/eldf/code/ci/9b33c8e266c379574ee10033b298499c77cfadb1/#diff-5])
. 11l[https://github.com/11l-lang/11l/commit/7e1de5a9c8ac324935d01aa60aaebebe0f3d8b8e]
}]]], я заметил, что в итоге я пришёл к записи номеров версий в виде/форме `ГГГГ.М[.н]`[[[ {если не ошибаюсь, [[[такую/]]]аналогичную форму версионирования я увидел впервые здесь[https://ru.wikipedia.org/wiki/CLion] («... с версии 2017.1 в CLion ...»)}]]]. После чего мне пришла идея [[[обозвать такое обозначение/]]]дать имя такому обозначению — YearVer [очевидно, по аналогии с SemVer]. А правило называния дополнительных версий {опубликованных в этом же месяце, либо исправляющих ошибки основной версии} составило основу [[[[данного сайта]]]описания]текста нового сайта.

Вскоре со страницы ‘Software versioning в Википедии’[https://en.wikipedia.org/wiki/Software_versioning] я узнал про существование CalVer. Это несколько разочаровало меня, но познакомившись поближе, я увидел, что сайт calver.org[https://calver.org] не даёт никаких конкретных рекомендаций, какую именно схему «календарного версионирования» следует использовать, а просто описывает уже [[[имеющиеся/]]]использующиеся схемы в различных проектах, никак не выделяя их.
Таким образом, [[[значимость/]]]создание сайта для YearVer осталось актуальным, и я принялся за продолжение [[[составления текста[[[ о YearVer]]]]]]его наполнения.

В итоге описание [[[системы/]]]схемы версинирования YearVer получилось достаточно небольшим, лаконичным, но очень определённым, предлагающим конкретные схемы/стратегии в зависимости от типа проекта.

Осталось теперь самое интересное[‘интересно, как справятся переводчики’] — перевести [[[сайт ]]]веб-страницу yearver.org/ru на английский с сохранением форматирования.

Чтобы сделать качественный перевод я решил обратиться сразу в три различных бюро переводов, причём сделав акцент на том, что меня интересует максимальное качество и я ‘готов доплатить’[‘справедливости ради, то, что я готов доплатить за качество, я указал при обращении только во второе и третье бюро переводов, а в сообщении для Alconost я указал только что ‘Требуется перевести очень небольшой по объёму текст, но очень качественно.’’] за него.
Я обратился в:
. Alconost (был первой ссылкой в результатах поиска в Google по запросу ‘бюро переводов сайтов’)
. transly.ru и tran.su (нашёл поиском по запросу ‘бюро переводов markdown’)

В процессе общения с первым бюро переводов были сформулированы правила чтения «древотекста»:
1. Скрытый текст 0‘{...}’ следует раскрывать после прочтения всего [соответствующего] абзаца целиком.
2.‘Скрытый текст 0‘{{...}}’ следует раскрывать после 0‘{...}’.

Например, в следующем предложении [со страницы [http://yearver.org/ru]]:
> Дополнительные версии, опубликованные в этом же месяце, либо 0‘{…}’ исправляющие ошибки основной версии 0‘{…}’, следует называть `2021.2.1`, `2021.2.2` и т.д.
вначале следует раскрыть второй блок скрытого текста (после слов ‘основной версии’), затем все его вложенные блоки, и только потом первый блок (после слова ‘либо’).
‘Почему именно так был составлен этот «древотекст»?’{
‘(Перед тем как читать [[[данное/]]]это пояснение я настоятельно рекомендую прочесть[[[ {и попробовать сформулировать самостоятельно почему он был так составлен}]]] [в соответствии с данными правилами] указанное[[[{[https://sinonim.org/s/данный][https://kartaslov.ru/синонимы-к-слову/данный]}]]] предложение со страницы yearver.org/ru целиком)’{
Второй блок скрытого текста (после слов ‘исправляющие ошибки основной версии’) вводит понятие безошибочных проектов, [[[подчёркивая/]]]поясняя, что в таких проектах не нужны версии ~‘исправляющие ошибки’. [И его [второй блок], в общем-то, можно было поместить сразу после слов ‘исправляющие ошибки’ [{но я не стал так делать, т.к. в этом случае первый и второй блоки скрытого текста [[[располагаются/]]]располагались бы слишком близко друг к другу}].]
А первый блок скрытого текста относится к слову ‘либо’ (поэтому и располагается сразу после него), но, так как в нём используется понятие безошибочных проектов [введённое во втором блоке], раскрывать его следует после второго блока [для чего первый блок и был заключён в дополнительные фигурные скобки].
}
}’

Теперь перейду к сравнению качества переводов.

Объективно оценить качество перевода достаточно трудно, но косвенным показателем является количество замечаний к переводу. Каждое замечание я оценил по шкале от 1 до 3 баллов [по возрастанию значимости].

‘Мои замечания к переводу от Alconost’{
```
\3/
in this case, core version `2021.2.1` might be released in another month
              ^^^^ (core здесь не нужно, т.к. в исходном тексте говорится
                   не об основной, а о дополнительной версии [`2021.2.1`])
\3/
If you want to provide a feedback, please submit a ‘GitHub request ’
                                                 ^^^^^^^^^^^^^^^^^^^
                                         (лучше ‘an issue on GitHub’)
\3/
released to fix bugs in the core version
                            ^^^^^^^^^^^^ (лучше base или main version)
\1/
`N`/`n` is the version number (starting with 1)
               ^^^^^^^ (лучше sequence)
\2/
each version can be (or must be) without bugfixes
                                         ^^^^^^^^ (лучше errors)
\2/
smaller ones, such as command-line tools
              ^^^^ (в исходном тексте имеется в виду другое)
\1/
those that can be tested by almost 100%
                  ^^^^^^
\1/
However, YearVer can be considered a subset of CalVer.
^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

\1/
For projects without bugfixes
    ^^^^^^^^^^^^^^^^^^^^^^^^^ (лучше errorless [или
                                     error-free] projects)
\2/
however, it is supposed that you don't release several new versions within a month
(не соответствует по смыслу оригиналу [‘но рекомендуется выпускать новые версии
                                        не чаще раза в месяц’])
\1/
The key idea behind YearVer
    ^^^^^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)
```

Итого: 20 баллов.

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/bdea486d21a2c1ae58d8c3de5d2df010e3a887ba/alconost.pq.txt].]

[[Стоимость перевода: 5637 ₽.]]
}
‘Мои замечания к переводу от transly.ru/toimetaja.eu (Välek OÜ)’{
```
\3/
Сломано форматирование:
><'N(1)' Year-based versioning
  ^^   ^
`2021.2.1` means 'an additional/new
                 ^
'What's wrong with SemVer?' {...}
^                         ^^
[а также ещё во многих местах]

\1/
Year-based versioning
           ^ (должно быть с заглавной буквы, т.к. это заголовок)

\3/
a version that fixes the major version [`2021.2`]
                         ^^^^^ (the major version is `2021`,
                                here should be ‘main version’)

\1/
Such a strategy is used by [https://www.jetbrains.com/clion/download/other.html] ...
   Должно быть:
Such a strategy is used[https://www.jetbrains.com/clion/download/other.html] by ...

\1/
Similarly to par. 2, except for `X`
             ^^^^ (не уверен, что это подходит тут
                   [нигде не встречал такого обозначения слова ‘пункт’])

\1/
However, YearVer can, of course, be considered a special
^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

\3/
If you would like to share your feedback, please submit a 'GitHub Request'
                                                        ^^^^^^^^^^^^^^^^^^
                                                (лучше ‘an issue on GitHub’)
\1/
The idea of YearVer
    ^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

\1/
SemVer[https://semver.org/lang/ru/] is a good option for
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (следовало заменить ссылку на
                                     английскую версию этого сайта)
```

Итого: 15 баллов.
[Несмотря на меньшее количество замечаний, по моему ощущению этот перевод менее качественный, чем от Alconost (слишком дословный, что-ли... больше похоже, что это именно перевод с русского, чем нативный текст на английском).]

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/3d6394328c9f521e2648fcef7fd27604e9133d97/transly.ru.pq.txt].]

[[Стоимость перевода: 4496 ₽.]]
}
‘Мои замечания к переводу от tran.su (Альянс ПРО)’{
```
\1/
Year-based versioning
           ^ (должно быть с заглавной буквы, т.к. это заголовок)

\1/
The idea of YearVer
    ^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

\1/
choose `2021.2.0` instead of `2021.2`.
^^^^^^ (по моему ощущению слово `choose` не очень подходит)

\3/
the version that fixes the major version [`2021.2`]
                           ^^^^^ (the major version is `2021`,
                                  here should be ‘main version’)
\1/
those fixing bugs in the major version
                         ^^^^^^^^^^^^^
in the same month as the major one
                         ^^^^^
(аналогично, здесь ‘major’ не уместно)

\2/
usually these are small utilities, e.g., command line tools
                                   ^^^^ (в исходном тексте имеется в виду другое)

\1/
this strategy is followed by JetBrains [https://www.jetbrains.com/...]
(некорректная ссылка, должно быть например:
this strategy is ‘followed by JetBrains’[https://www.jetbrains.com/...]
)

\1/
'Thus, YearVer (with versions like `YYYY.X` and `YYYY.X.Z`) considers 3 choices'{...}
^                                                                              ^
(сломано форматирование [и ещё в паре мест парные кавычки ‘ и ’ заменены на '])

\2/
For bug-fixing projects
    ^^^^^^^^^^^^^^^^^^^ (не соответствует по смыслу оригиналу)

\1/
Of course, YearVer can be viewed as a special case of CalVer
^ (я бы добавил ‘But’ в начало)
```

Итого: 14 баллов.

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/02d3b9f622e20b85e137a4dce3db499ab5fd018f/tran.su.pq.txt].]

[[Стоимость перевода: 4050 ₽.]]
}

В заключение [процесса перевода] осталось проделать кропотливую работу по «слиянию» трёх полученных переводов в один текст, выбрав лучшие варианты [[[для ]]]перевода каждого предложения и каждого термина/понятия.

‘А почему «древопись»?’{[[[На основе #audio#REC_0000356.wav
]]]Если представить дерево как структуру данных [в программировании], то действительно не очень понятно, как «древопись» с ним соотносится. Но если посмотреть на обычные деревья[[[ и попробовать написать «древотекст» на дереве, то]]]... Попробуйте на листе бумаги провести вертикальную черту — это ствол дерева, и это ваш текст [абзац или просто предложение]. Теперь нужно идти снизу вверх и дойдя до первого блока скрытого текста [[[нужно/]]]следует сделать ответвление (влево или вправо {можно чередовать: первый блок скрытого текста — ответвление влево, второй — вправо, третий — опять влево и т.д.}). Затем раскрываем первый блок скрытого текста [нижняя ветвь дерева]. Он [[[также ]]]может состоять либо из простого текста, либо содержать в себе другие блоки скрытого текста, соответствующие подветвям ~‘д’е~‘рева’. Потому и «~‘древо’пись».[[[В принципе, классический спойлер также можно считать формой «древописи».]]]

‘А в чём отличие от классических спойлеров (вроде этого[[[/такого]]])?’{
«Древопись» — это блоки скрытого текста внутри абзаца.
А классический спойлер — это сам по себе отдельный абзац {но который, также как и блок скрытого текста «древописи», может [[[состоять из нескольких/]]]содержать в себе несколько абзацев}.
}[[[
> А [[[где-то можно научиться/]]]где учат писать «древотекст»?
< Нигде, так как это встроенная способность мозга, которая активируется автоматически {или не активируется... это как повезёт[[[.]]] :)(:} при виде «древотекста».
]]][[[
> Чем отличается «древопись» от «древотекста»?
< «Древопись» — это технология письменности, а «древотекст» — это текст, написанный по этой технологии.
]]]
}

‘Про области применения’{
«Древопись» можно использовать не только для написания статей и документации, но и для... анекдотов.
‘Пара примеров’{
Т‘Н‘‘Используя классический спойлер’ ‘«Древотекст»’’

‘‘Я могу прыгнуть выше Исаакиевского Собора.
Вот я прыгнул.
‘.......’{Теперь пусть прыгает Исаакиевский Собор.}’

‘‘***’{
Я могу прыгнуть выше Исаакиевского Собора.
Вот я прыгнул. {
Теперь пусть прыгает Исаакиевский Собор.}
}’’

‘‘Эйнштейн умерший попадает в рай.
Его принимает Господь, и говорит ему: «тебе что-нибудь хочется узнать у меня, или что-то попросить?»
Тот говорит: «Да. Можешь ли ты написать формулу того, как ты всё это сделал?»
Бог [[[говорит/]]]отвечает: «Могу.»
Он [Бог] что-то пишет-пишет.
‘.......’{
И вдруг Эйнштейн говорит: «Да подождите! Там же... ошибка!»
Бог [смущённо]:
‘.......’{«Да, я знаю...»}
}’

‘‘***’{
Эйнштейн умерший попадает в рай.
Его принимает Господь, и говорит ему: «тебе что-нибудь хочется узнать у меня, или что-то попросить?»
Тот говорит: «Да. Можешь ли ты написать формулу того, как ты всё это сделал?»
Бог [[[говорит/]]]отвечает: «Могу.»
Он [Бог] что-то пишет-пишет. {
И вдруг Эйнштейн говорит: «Да подождите! Там же... ошибка!»
Бог [смущённо]: {«Да, я знаю...»}}
}’’
’
}
}

'‘’'

## 7.ru.pq.txt
Н(1)‘Новая технология письменности («древопись») на примере сайта YearVer’

[[[
Метки: древопись, древотекст, yearver, двуязычная статья
]]]

Со времени появления ‘первого языка разметки текста, который поддерживает «древопись»’[https://habr.com/ru/post/348218/], прошло вот уже несколько лет, однако достойного текста, демонстрирующего преимущества новой технологии письменности, так и не появилось.

И самым большим «древотекстом» была пара абзацев из ‘документации к пк-разметке’[http://pqmarkup.org/ru/syntax] {‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’}, которые составляют всего ~1300 знаков, и которые доступны только на русском языке.

А на английском языке «древотекста» как такового не было вообще [не считая маленькие вставки в документации к языку программирования 11l (например ‘Boolean type’ в ‘Built-in types’[http://11l-lang.org/doc/built-in-types])].

Но в этом году...
'‘<cut />’'
...когда я приводил в порядок мета-информацию[‘в частности, номера версий, а также статус [Beta/Stable]’] своих проектов, я заметил, что в итоге я пришёл к записи номеров версий в виде/форме `ГГГГ.М[.н]`. После чего мне пришла идея дать имя такому обозначению — YearVer [очевидно, по аналогии с SemVer]. А правило называния дополнительных версий {опубликованных в этом же месяце, либо исправляющих ошибки основной версии} составило основу текста нового сайта.

Вскоре со страницы ‘Software versioning в Википедии’[https://en.wikipedia.org/wiki/Software_versioning] я узнал про существование CalVer. Это несколько разочаровало меня, но познакомившись поближе, я увидел, что сайт calver.org не даёт никаких конкретных рекомендаций, какую именно схему «календарного версионирования» следует использовать, а просто описывает уже использующиеся схемы в различных проектах, никак не выделяя их.
Таким образом, создание сайта для YearVer осталось актуальным, и я принялся за продолжение его наполнения.

В итоге описание схемы версинирования YearVer получилось достаточно небольшим, лаконичным, но очень определённым, предлагающим конкретные схемы/стратегии в зависимости от типа проекта.

Осталось теперь самое интересное — перевести веб-страницу yearver.org/ru на английский с сохранением форматирования.

Чтобы сделать качественный перевод я решил обратиться сразу в три различных бюро переводов, причём сделав акцент на том, что меня интересует максимальное качество и я ‘готов доплатить’[‘справедливости ради, то, что я готов доплатить за качество, я указал при обращении только во второе и третье бюро переводов, а в сообщении для Alconost я указал только что ‘Требуется перевести очень небольшой по объёму текст, но очень качественно.’’] за него.
Я обратился в:
. Alconost (был первой ссылкой в результатах поиска в Google по запросу ‘бюро переводов сайтов’)
. transly.ru и tran.su (нашёл поиском по запросу ‘бюро переводов markdown’)

В процессе общения с первым бюро переводов были сформулированы правила чтения «древотекста»:
1. Скрытый текст 0‘{...}’ следует раскрывать после прочтения всего [соответствующего] абзаца целиком.
2.‘Скрытый текст 0‘{{...}}’ следует раскрывать после 0‘{...}’.

Например, в следующем предложении [со страницы [http://yearver.org/ru]]:
> Дополнительные версии, опубликованные в этом же месяце, либо 0‘{…}’ исправляющие ошибки основной версии 0‘{…}’, следует называть `2021.2.1`, `2021.2.2` и т.д.
вначале следует раскрыть второй блок скрытого текста (после слов ‘основной версии’), затем все его вложенные блоки, и только потом первый блок (после слова ‘либо’).
‘Почему именно так был составлен этот «древотекст»?’{
‘(Перед тем как читать это пояснение я настоятельно рекомендую прочесть [в соответствии с данными правилами] указанное предложение со страницы yearver.org/ru целиком)’{
Второй блок скрытого текста (после слов ‘исправляющие ошибки основной версии’) вводит понятие безошибочных проектов, поясняя, что в таких проектах не нужны версии ~‘исправляющие ошибки’. [И его [второй блок], в общем-то, можно было поместить сразу после слов ‘исправляющие ошибки’ [{но я не стал так делать, т.к. в этом случае первый и второй блоки скрытого текста располагались бы слишком близко друг к другу}].]
А первый блок скрытого текста относится к слову ‘либо’ (поэтому и располагается сразу после него), но, так как в нём используется понятие безошибочных проектов [введённое во втором блоке], раскрывать его следует после второго блока [для чего первый блок и был заключён в дополнительные фигурные скобки].
}
}’

Теперь перейду к сравнению качества переводов.

Объективно оценить качество перевода достаточно трудно, но косвенным показателем является количество замечаний к переводу. Каждое замечание я оценил по шкале от 1 до 3 баллов [по возрастанию значимости].

‘Мои замечания к переводу от Alconost’{
```
\3/
in this case, core version `2021.2.1` might be released in another month
              ^^^^ (core здесь не нужно, т.к. в исходном тексте говорится
                   не об основной, а о дополнительной версии [`2021.2.1`])
\3/
If you want to provide a feedback, please submit a ‘GitHub request ’
                                                 ^^^^^^^^^^^^^^^^^^^
                                         (лучше ‘an issue on GitHub’)
\3/
released to fix bugs in the core version
                            ^^^^^^^^^^^^ (лучше base или main version)
\1/
`N`/`n` is the version number (starting with 1)
               ^^^^^^^ (лучше sequence)
\2/
each version can be (or must be) without bugfixes
                                         ^^^^^^^^ (лучше errors)
\2/
smaller ones, such as command-line tools
              ^^^^ (в исходном тексте имеется в виду другое)
\1/
those that can be tested by almost 100%
                  ^^^^^^
\1/
However, YearVer can be considered a subset of CalVer.
^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

\1/
For projects without bugfixes
    ^^^^^^^^^^^^^^^^^^^^^^^^^ (лучше errorless [или
                                     error-free] projects)
\2/
however, it is supposed that you don't release several new versions within a month
(не соответствует по смыслу оригиналу [‘но рекомендуется выпускать новые версии
                                        не чаще раза в месяц’])
\1/
The key idea behind YearVer
    ^^^^^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)
```

Итого: 20 баллов.

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/bdea486d21a2c1ae58d8c3de5d2df010e3a887ba/alconost.pq.txt].]

[[Стоимость перевода: 5637 ₽.]]
}
‘Мои замечания к переводу от transly.ru/toimetaja.eu (Välek OÜ)’{
```
\3/
Сломано форматирование:
><'N(1)' Year-based versioning
  ^^   ^
`2021.2.1` means 'an additional/new
                 ^
'What's wrong with SemVer?' {...}
^                         ^^
[а также ещё во многих местах]

\1/
Year-based versioning
           ^ (должно быть с заглавной буквы, т.к. это заголовок)

\3/
a version that fixes the major version [`2021.2`]
                         ^^^^^ (the major version is `2021`,
                                here should be ‘main version’)

\1/
Such a strategy is used by [https://www.jetbrains.com/clion/download/other.html] ...
   Должно быть:
Such a strategy is used[https://www.jetbrains.com/clion/download/other.html] by ...

\1/
Similarly to par. 2, except for `X`
             ^^^^ (не уверен, что это подходит тут
                   [нигде не встречал такого обозначения слова ‘пункт’])

\1/
However, YearVer can, of course, be considered a special
^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

\3/
If you would like to share your feedback, please submit a 'GitHub Request'
                                                        ^^^^^^^^^^^^^^^^^^
                                                (лучше ‘an issue on GitHub’)
\1/
The idea of YearVer
    ^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

\1/
SemVer[https://semver.org/lang/ru/] is a good option for
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (следовало заменить ссылку на
                                     английскую версию этого сайта)
```

Итого: 15 баллов.
[Несмотря на меньшее количество замечаний, по моему ощущению этот перевод менее качественный, чем от Alconost (слишком дословный, что-ли... больше похоже, что это именно перевод с русского, чем нативный текст на английском).]

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/3d6394328c9f521e2648fcef7fd27604e9133d97/transly.ru.pq.txt].]

[[Стоимость перевода: 4496 ₽.]]
}
‘Мои замечания к переводу от tran.su (Альянс ПРО)’{
```
\1/
Year-based versioning
           ^ (должно быть с заглавной буквы, т.к. это заголовок)

\1/
The idea of YearVer
    ^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

\1/
choose `2021.2.0` instead of `2021.2`.
^^^^^^ (по моему ощущению слово `choose` не очень подходит)

\3/
the version that fixes the major version [`2021.2`]
                           ^^^^^ (the major version is `2021`,
                                  here should be ‘main version’)
\1/
those fixing bugs in the major version
                         ^^^^^^^^^^^^^
in the same month as the major one
                         ^^^^^
(аналогично, здесь ‘major’ не уместно)

\2/
usually these are small utilities, e.g., command line tools
                                   ^^^^ (в исходном тексте имеется в виду другое)

\1/
this strategy is followed by JetBrains [https://www.jetbrains.com/...]
(некорректная ссылка, должно быть например:
this strategy is ‘followed by JetBrains’[https://www.jetbrains.com/...]
)

\1/
'Thus, YearVer (with versions like `YYYY.X` and `YYYY.X.Z`) considers 3 choices'{...}
^                                                                              ^
(сломано форматирование [и ещё в паре мест парные кавычки ‘ и ’ заменены на '])

\2/
For bug-fixing projects
    ^^^^^^^^^^^^^^^^^^^ (не соответствует по смыслу оригиналу)

\1/
Of course, YearVer can be viewed as a special case of CalVer
^ (я бы добавил ‘But’ в начало)
```

Итого: 14 баллов.

[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/02d3b9f622e20b85e137a4dce3db499ab5fd018f/tran.su.pq.txt].]

[[Стоимость перевода: 4050 ₽.]]
}

В заключение [процесса перевода] осталось проделать кропотливую работу по «слиянию» трёх полученных переводов в один текст, выбрав лучшие варианты перевода каждого предложения и каждого термина/понятия.


‘А почему «древопись»?’{Если представить дерево как структуру данных [в программировании], то действительно не очень понятно, как «древопись» с ним соотносится. Но если посмотреть на обычные деревья... Попробуйте на листе бумаги провести вертикальную черту — это ствол дерева, и это ваш текст [абзац или просто предложение]. Теперь нужно идти снизу вверх и дойдя до первого блока скрытого текста следует сделать ответвление (влево или вправо {можно чередовать: первый блок скрытого текста — ответвление влево, второй — вправо, третий — опять влево и т.д.}). Затем раскрываем первый блок скрытого текста [нижняя ветвь дерева]. Он может состоять либо из простого текста, либо содержать в себе другие блоки скрытого текста, соответствующие подветвям ~‘д’е~‘рева’. Потому и «~‘древо’пись».[[[В принципе, классический спойлер также можно считать формой «древописи».]]]

‘А в чём отличие от классических спойлеров (вроде этого)?’{
«Древопись» — это блоки скрытого текста внутри абзаца.
А классический спойлер — это сам по себе отдельный абзац {но который, также как и блок скрытого текста «древописи», может содержать в себе несколько абзацев}.
}
[[[
> Чем отличается «древопись» от «древотекста»?
< «Древопись» — это технология письменности, а «древотекст» — это текст, написанный по этой технологии.
]]]}

## alconost.pq.txt
><‘Н(1)‘Year-Based Versioning
(YearVer)’’


The key idea behind YearVer is to denote versions in the following formats: `YYYY.M`, `YYYY.N`, `YYYY.N.n` or `YYYY.M.n` {
`YYYY` is the year
`M` is the month (1 to 12)
`N`/`n` is the version number (starting with 1)
}.


If you need 3 numbers separated by full stops [e.g. as in npm {
```
npm ERR! Invalid version: "2021.2"
```
>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
the version number can only be like `\d+\.\d+\.\d+`’
}], then simply use `2021.2.0` instead of `2021.2`.


Additional versions published in the same month or {{

For example, if you choose the first strategy, then version `2021.2.1` would denote ‘an additional/new version released in the same month as the core version [i.e. in February]’, and if you choose the second strategy, then this version would denote ‘a version that fixes bugs in the core version [`2021.2`] {in this case, core version `2021.2.1` might be released in another month}’.

The second strategy allows using the second digit in the version number as index [of the version released in the corresponding year] instead of month. For example, this strategy is adopted[https://www.jetbrains.com/clion/download/other.html] by JetBrains.

‘Thus, YearVer (i.e. version formats `YYYY.X` and `YYYY.X.Z`) provides you with 3 options’{
1. For projects without bugfixes, `X` is the month in which this version was released and `Z` is the number of an additional/new version released in the same month {however, it is supposed that you don't release several new versions within a month}.
2. For projects with bugfixes, `X` is the month in which this version was released and `Z` is the number of a bugfix version [that might be released in another month] resolving bugs in version `YYYY.X` or `YYYY.X.(Z-1)`.
3. Similar to option 2, except that `X` is not a month, but an index [starting with 1] within the corresponding year. [This strategy is adopted by JetBrains.]
}

}} released to fix bugs in the core version {make sure to choose the strategy that best suits your project {in certain projects {smaller ones, such as command-line tools [and those that can be tested by almost 100%]}, each version can be (or must be) without bugfixes [{it's quite obvious that such projects don't need bugfix versions}]}} should be denoted as `2021.2.1`, `2021.2.2`, and so on.


‘What's wrong with SemVer?’{
SemVer[https://semver.org] is nice for versions below 1.0.0 or certain types of projects, but many SemVer principles, including how to increase the major version number, seem questionable. For example, if you change the name of an API function, would it be enough to increase the major version number?

Other disadvantages of SemVer are described here[https://sedimental.org/designing_a_version.html <- https://calver.org].
}


‘What's wrong with CalVer?’{
Its specification is too vague.
However, YearVer can be considered a subset of CalVer[https://calver.org].
}


If you want to provide a feedback, please submit a ‘GitHub request ’[https://github.com/yearver/yearver/issues].

## tran.su.pq.txt
><‘Н(1)‘Year-based versioning
(YearVer)’’


The idea of YearVer is to assign version numbers in the format of `YYYY.M`, `YYYY.N`, `YYYY.N.n`, or `YYYY.M.n` {
`YYYY` is the full year
`M` is the month (a number from 1 to 12)
`N`/`n` is an incremented 1-based number
}.


If you need 3 numbers separated by a dot [like in npm {
```
npm ERR! Invalid version: "2021.2"
```
>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
the version number can only be like `\d+\.\d+\.\d+`’
}], choose `2021.2.0` instead of `2021.2`.


Additional versions published in the same month, or {{

This means that when choosing the first strategy, the version number `2021.2.1` means 'an additional/new version released in the same month as the major one [i.e., in February]', while in the second strategy, the same version number means 'the version that fixes the major version [`2021.2`] {also, the version `2021.2.1` itself may not have necessarily been released in February}'.

The second strategy allows the second digit in the version number to be an incremented number [representing a version within the given year], instead of the month. For example, this strategy is followed by JetBrains [https://www.jetbrains.com/clion/download/other.html].

'Thus, YearVer (with versions like `YYYY.X` and `YYYY.X.Z`) considers 3 choices'{
1. For error-free projects, `X` stands for the month of the given version release, and `Z` stands for the additional/new version number in the same month {however, it is recommended to release new versions no more than once a month}.
2. For bug-fixing projects, `X` stands for the month of the given version release, and `Z` is the version number [not necessarily released in the same month] that fixes the errors of the `YYYY.X` or `YYYY.X.(Z-1)` version.
3. Similar to choice 2, only `X` is not the month, but an incremented 1-based number within the corresponding year. [JetBrains' strategy.]
}

}} those fixing bugs in the major version {you should decide and choose the most appropriate strategy depending on your project {there are projects {usually these are small utilities, e.g., command line tools [and projects having nearly 100% code coverage]} each version of which should/can be error-free [{obviously, these projects do not need bug-fixing versions}]}}, shall be numbered `2021.2.1`, `2021.2.2`, and so on.


‘What's wrong with SemVer?’{
SemVer [https://semver.org] works well for versions below 1.0.0 and for certain project types. However, many SemVer provisions raise questions, including the condition of the major version increment. For example, if you change the name of an API function, will that be enough to increase the major version?

You can find other arguments against SemVer here[https://sedimental.org/designing_a_version.html <- https://calver.org].
}


‘What's wrong with CalVer?’{
The CalVer specification is too vague {calver.org fails to give any specific recommendations on a calendar versioning scheme to choose; it simply describes the schemes already used in various projects, without highlighting them in any way}.
Of course, YearVer can be viewed as a special case of CalVer[https://calver.org].
}


If you'd like to provide feedback, please add a ‘New issue on GitHub’[https://github.com/yearver/yearver/issues].

## transly.ru.pq.txt
><'N(1)' Year-based versioning
(YearVer)’’


The idea of YearVer is to specify version numbers in the form of `YYYY.M`,` YYYY.N`, `YYYY.N.n` or` YYYY.M.n` {
`YYYY` is a year
`М` is a month (any number from 1 to 12)
`N`/`n’ is a sequential number (starting from 1)
}.


If you need 3 numbers separated by a dot [for example, as in npm {
```
npm ERR! Invalid version: "2021.2"
```
>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
the version number can only be like `\d+\.\d+\.\d+`’
}], you can use `2021.2.0` instead of` 2021.2`.


Additional versions published in the same month, or {{

This means that, when choosing the first strategy, the version, for example, `2021.2.1` means 'an additional/new version released in the same month as the main one [i.e. in February]', and when choosing the second strategy, the same version number means ‘a version that fixes the major version [`2021.2`] {though the version` 2021.2.1` itself does not have to be released in February}'.

When choosing the second strategy, it is allowed to use the second digit of the version number as a sequential number [of the version in the corresponding year], and not as a month number. Such a strategy is used by [https://www.jetbrains.com/clion/download/other.html], for example, JetBrains.

'Thus, YearVer (designating a version in the form of `YYYY.X` and` YYYY.X.Z`) has 3 choices'{
1. For error-free projects, the number `X` stands for a month number in which the given version was released, and the `Z` stands for an additional/new version number in the same month {however, it is recommended to release new versions no more than once a month}.
2. For projects that allow bug-fixing, the number `X`is the month number in which the version was released, and `Z` is the version number [not necessarily released in the same month] that fixes the errors of the version `YYYY.X` or `YYYY.X.(Z-1)`.
3. Similarly to par. 2, except for `X`, that does not stand for a month number, but a sequential number [starting from 1] within the corresponding year. [JetBrains strategy.]
}

}} fixing the bugs of the main version {you should decide and choose the most appropriate strategy depending on the project {there are projects {usually small in size, whereas in terms of the form they are usually command line utilities [and projects that can be covered by tests almost by 100%]} where each version must/can be bug-free [{obviously, such projects do not need bug-fixing versions}]}}, should be designated as `2021.2.1`, `2021.2.2`, etc.


'What's wrong with SemVer?' {
SemVer[https://semver.org/lang/ru/] is a good option for versions below 1.0.0 or for some types of projects, however many SemVer provisions raise questions, including the condition of raising the major version. For example, if you change the name of an API function, is that enough to increase the major version?

You can find other arguments against SemVer here[https://sedimental.org/designing_a_version.html <- https://calver.org].
}


'What's wrong with CalVer?'{
The specification is too vague.
However, YearVer can, of course, be considered a special instance of CalVer[https://calver.org].
}


If you would like to share your feedback, please submit a 'GitHub Request'[https://github.com/yearver/yearver/issues].
	[[[
	[[[Хабы: Локализация продуктов, Мозг]]]
	[[[Header: A new writing method/technology (“dendrowriting”), as exemplified by the YearVer site]]]
	[[[Tags: dendrowriting, dendrotext, yearver, bilingual article, двуязычная статья]]]
	]]]
	Several years have passed since the appearance of ‘the first text markup language that supports “dendrowriting”’[https://pqmarkup.org], but no worthwhile piece of text demonstrating the advantages of the new writing method/technology has yet appeared.

	The largest “dendrotext” was a couple of paragraphs in the ‘pqmarkup documentation’[http://pqmarkup.org/ru/syntax ‘‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’’], consisting of only ~1300 characters and available only in Russian.

	In English there was no “dendrotext” at all, as such [apart from small insertions in the documentation for the 11l programming language (e.g., ‘Boolean type’ in ‘Built-in types’[http://11l-lang.org/doc/built-in-types])].

	But [[[this/]]]last year...
	'‘<cut />’'
	... when I was tidying up the meta-information[‘specifically the version numbers and status [Beta/Stable]’] for my projects, I noticed that I had settled on recording version numbers in `YYYY.M[.n]` form. Then I got the idea of giving this designation a name: YearVer [obviously, by analogy with SemVer]. And the rule for naming additional versions {published in the same month or fixing bugs in the main version} formed the basis of the text for a new website.

	Soon after, I learned about the existence of CalVer from the ‘Software versioning page on Wikipedia’[https://en.wikipedia.org/wiki/Software_versioning]. This disappointed me a little, but when I took a closer look I found out that calver.org[https://calver.org] does not give any specific recommendations about which “calendar versioning” scheme should be used, but simply describes the schemes already used in various projects, without highlighting them in any way.
	The creation of a site for YearVer thus remained relevant, and I continued to fill it with content.

	The resulting description of the YearVer versioning scheme turned out to be quite short and concise, but very definite, offering specific schemes/strategies depending on the type of project.

	And the most challenging task was now to translate the yearver.org/ru page into English, preserving the formatting.

	To obtain a high-quality translation, I decided to contact three different translation agencies at once and to emphasize the fact that I was interested in maximum quality and ‘prepared to pay extra’[‘for the sake of fairness I should say it was only the second and third translation agencies I told I was prepared to pay extra for quality; in my message to Alconost I just indicated that ‘I need a very small text translated, but to a very high quality’’] for it.
	I contacted:
	. Alconost (it was the first link in Google search results for ‘бюро переводов сайтов’\‘website translation agency’)
	. transly.ru and tran.su (found by searching for ‘бюро переводов markdown’\‘translation agency markdown’)

	In the process of communicating with the first translation agency, the rules for reading “dendrotext” were formulated:
	1. Hidden text 0‘{...}’ should be expanded only after the [corresponding] paragraph has been read in its entirety.
	2.‘Hidden text 0‘{{...}}’ should be expanded after 0‘{...}’.

	For example, in the following sentence [from [http://yearver.org]]:
	> Additional versions published in the same month, or 0‘{…}’ those fixing bugs of the main version 0‘{…}’, shall be numbered `2021.2.1`, `2021.2.2`, and so on.
	the second block of hidden text should be expanded (after the words ‘main version’), then all its nested blocks, and only then the first block (after the word ‘or’).
	‘Why was this “dendrotext” organized this way?’{
	‘(Before reading this explanation, I strongly recommend that you read [in accordance with these rules] the indicated sentence from yearver.org in full)’{
	The second block of hidden text (after the words ‘those fixing bugs of the main version’) introduces the concept of bug-free projects, clarifying that such projects do not need bug-fixing versions. [And its [second block] could actually be placed right after the words ‘fixing bugs’ [{but I did not do that, since the first and second blocks of hidden text would then be too close to each other}].]
	And the first block of the hidden text relates to the word ‘or’ (therefore it is located immediately after it), but since it uses the concept of bug-free projects [introduced in the second block], it should be expanded after the second block [which is why the first block was enclosed in additional curly braces].
	}
	}’

	At the end [of the translation process] there remained the painstaking work of “merging” the three translations I received into one text, choosing the best translation variants for each sentence and each term/concept.

	‘Why “dendrowriting”?’{~‘Dendro-’ comes[https://www.dictionary.com/browse/dendro- <- google:‘dendro dictionary meaning’] from the Greek ~‘déndron’, meaning “tree”. However, if you think of a tree as a data structure [in programming], then it's really not very clear how “dendrowriting” relates to it. But if you take a look at ordinary/real trees... Try to draw a vertical line on a piece of paper: that's the trunk of the tree, and this is your text [a paragraph or just a sentence]. Now go from bottom to top, and once you reach the first block of hidden text, make a branch (to the left or to the right {you can alternate: the first block of hidden text branches to the left, the second to the right, the third to the left again, etc.}). Then you expand the first block of hidden text [bottom branch of the tree]. It can either consist of plain text or contain other blocks of hidden text corresponding to the sub-branches of the tree.[[[In principle, a classic spoiler can also be considered a form of “dendrowriting”.]]]

	‘And how is it different from classic spoilers (like this)?’{
	“Dendrowriting” is blocks of hidden text within a paragraph.
	Whereas the classic spoiler is a separate paragraph in itself {but which, like a block of hidden text in “dendrowriting”, may contain multiple paragraphs}.
	}
	[[[
	> What is the difference between “dendrowriting” and “dendrotext”?
	< “Dendrowriting” is a writing technology, and “dendrotext” is a text written using that technology.
	]]]}

	'‘’'
	Н(1)‘Новая технология письменности («древопись») на примере сайта YearVer’

	[[[
	Метки: древопись, древотекст, yearver, двуязычная статья
	]]]

	Со времени появления ‘первого языка разметки текста, который поддерживает «древопись»’[https://habr.com/ru/post/348218/], прошло вот уже несколько лет, однако достойного текста, демонстрирующего преимущества новой технологии письменности, так и не появилось.

	И самым большим «древотекстом» была пара абзацев из ‘документации к пк-разметке’[http://pqmarkup.org/ru/syntax] {‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’}, которые составляют всего ~1300 знаков, и которые доступны только на русском языке.

	А на английском языке «древотекста» как такового не было вообще [не считая маленькие вставки в документации к языку программирования 11l (например ‘Boolean type’ в ‘Built-in types’[http://11l-lang.org/doc/built-in-types])].

	Но в этом году...
	'‘<cut />’'
	...когда я приводил в порядок мета-информацию[‘в частности, номера версий, а также статус [Beta/Stable]’] своих проектов, я заметил, что в итоге я пришёл к записи номеров версий в виде/форме `ГГГГ.М[.н]`. После чего мне пришла идея дать имя такому обозначению — YearVer [очевидно, по аналогии с SemVer]. А правило называния дополнительных версий {опубликованных в этом же месяце, либо исправляющих ошибки основной версии} составило основу текста нового сайта.

	Вскоре со страницы ‘Software versioning в Википедии’[https://en.wikipedia.org/wiki/Software_versioning] я узнал про существование CalVer. Это несколько разочаровало меня, но познакомившись поближе, я увидел, что сайт calver.org не даёт никаких конкретных рекомендаций, какую именно схему «календарного версионирования» следует использовать, а просто описывает уже использующиеся схемы в различных проектах, никак не выделяя их.
	Таким образом, создание сайта для YearVer осталось актуальным, и я принялся за продолжение его наполнения.

	В итоге описание схемы версинирования YearVer получилось достаточно небольшим, лаконичным, но очень определённым, предлагающим конкретные схемы/стратегии в зависимости от типа проекта.

	Осталось теперь самое интересное — перевести веб-страницу yearver.org/ru на английский с сохранением форматирования.

	Чтобы сделать качественный перевод я решил обратиться сразу в три различных бюро переводов, причём сделав акцент на том, что меня интересует максимальное качество и я ‘готов доплатить’[‘справедливости ради, то, что я готов доплатить за качество, я указал при обращении только во второе и третье бюро переводов, а в сообщении для Alconost я указал только что ‘Требуется перевести очень небольшой по объёму текст, но очень качественно.’’] за него.
	Я обратился в:
	. Alconost (был первой ссылкой в результатах поиска в Google по запросу ‘бюро переводов сайтов’)
	. transly.ru и tran.su (нашёл поиском по запросу ‘бюро переводов markdown’)

	В процессе общения с первым бюро переводов были сформулированы правила чтения «древотекста»:
	1. Скрытый текст 0‘{...}’ следует раскрывать после прочтения всего [соответствующего] абзаца целиком.
	2.‘Скрытый текст 0‘{{...}}’ следует раскрывать после 0‘{...}’.

	Например, в следующем предложении [со страницы [http://yearver.org/ru]]:
	> Дополнительные версии, опубликованные в этом же месяце, либо 0‘{…}’ исправляющие ошибки основной версии 0‘{…}’, следует называть `2021.2.1`, `2021.2.2` и т.д.
	вначале следует раскрыть второй блок скрытого текста (после слов ‘основной версии’), затем все его вложенные блоки, и только потом первый блок (после слова ‘либо’).
	‘Почему именно так был составлен этот «древотекст»?’{
	‘(Перед тем как читать это пояснение я настоятельно рекомендую прочесть [в соответствии с данными правилами] указанное предложение со страницы yearver.org/ru целиком)’{
	Второй блок скрытого текста (после слов ‘исправляющие ошибки основной версии’) вводит понятие безошибочных проектов, поясняя, что в таких проектах не нужны версии ~‘исправляющие ошибки’. [И его [второй блок], в общем-то, можно было поместить сразу после слов ‘исправляющие ошибки’ [{но я не стал так делать, т.к. в этом случае первый и второй блоки скрытого текста располагались бы слишком близко друг к другу}].]
	А первый блок скрытого текста относится к слову ‘либо’ (поэтому и располагается сразу после него), но, так как в нём используется понятие безошибочных проектов [введённое во втором блоке], раскрывать его следует после второго блока [для чего первый блок и был заключён в дополнительные фигурные скобки].
	}
	}’

	Теперь перейду к сравнению качества переводов.

	Объективно оценить качество перевода достаточно трудно, но косвенным показателем является количество замечаний к переводу. Каждое замечание я оценил по шкале от 1 до 3 баллов [по возрастанию значимости].

	‘Мои замечания к переводу от Alconost’{
	```
	\3/
	in this case, core version `2021.2.1` might be released in another month
	^^^^ (core здесь не нужно, т.к. в исходном тексте говорится
	не об основной, а о дополнительной версии [`2021.2.1`])
	\3/
	If you want to provide a feedback, please submit a ‘GitHub request ’
	^^^^^^^^^^^^^^^^^^^
	(лучше ‘an issue on GitHub’)
	\3/
	released to fix bugs in the core version
	^^^^^^^^^^^^ (лучше base или main version)
	\1/
	`N`/`n` is the version number (starting with 1)
	^^^^^^^ (лучше sequence)
	\2/
	each version can be (or must be) without bugfixes
	^^^^^^^^ (лучше errors)
	\2/
	smaller ones, such as command-line tools
	^^^^ (в исходном тексте имеется в виду другое)
	\1/
	those that can be tested by almost 100%
	^^^^^^
	\1/
	However, YearVer can be considered a subset of CalVer.
	^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

	\1/
	For projects without bugfixes
	^^^^^^^^^^^^^^^^^^^^^^^^^ (лучше errorless [или
	error-free] projects)
	\2/
	however, it is supposed that you don't release several new versions within a month
	(не соответствует по смыслу оригиналу [‘но рекомендуется выпускать новые версии
	не чаще раза в месяц’])
	\1/
	The key idea behind YearVer
	^^^^^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)
	```

	Итого: 20 баллов.

	[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/bdea486d21a2c1ae58d8c3de5d2df010e3a887ba/alconost.pq.txt].]

	[[Стоимость перевода: 5637 ₽.]]
	}
	‘Мои замечания к переводу от transly.ru/toimetaja.eu (Välek OÜ)’{
	```
	\3/
	Сломано форматирование:
	><'N(1)' Year-based versioning
	^^ ^
	`2021.2.1` means 'an additional/new
	^
	'What's wrong with SemVer?' {...}
	^ ^^
	[а также ещё во многих местах]

	\1/
	Year-based versioning
	^ (должно быть с заглавной буквы, т.к. это заголовок)

	\3/
	a version that fixes the major version [`2021.2`]
	^^^^^ (the major version is `2021`,
	here should be ‘main version’)

	\1/
	Such a strategy is used by [https://www.jetbrains.com/clion/download/other.html] ...
	Должно быть:
	Such a strategy is used[https://www.jetbrains.com/clion/download/other.html] by ...

	\1/
	Similarly to par. 2, except for `X`
	^^^^ (не уверен, что это подходит тут
	[нигде не встречал такого обозначения слова ‘пункт’])

	\1/
	However, YearVer can, of course, be considered a special
	^^^^^^^ (тут имеется в виду не ‘однако’, а ‘но разумеется’)

	\3/
	If you would like to share your feedback, please submit a 'GitHub Request'
	^^^^^^^^^^^^^^^^^^
	(лучше ‘an issue on GitHub’)
	\1/
	The idea of YearVer
	^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

	\1/
	SemVer[https://semver.org/lang/ru/] is a good option for
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (следовало заменить ссылку на
	английскую версию этого сайта)
	```

	Итого: 15 баллов.
	[Несмотря на меньшее количество замечаний, по моему ощущению этот перевод менее качественный, чем от Alconost (слишком дословный, что-ли... больше похоже, что это именно перевод с русского, чем нативный текст на английском).]

	[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/3d6394328c9f521e2648fcef7fd27604e9133d97/transly.ru.pq.txt].]

	[[Стоимость перевода: 4496 ₽.]]
	}
	‘Мои замечания к переводу от tran.su (Альянс ПРО)’{
	```
	\1/
	Year-based versioning
	^ (должно быть с заглавной буквы, т.к. это заголовок)

	\1/
	The idea of YearVer
	^^^^ (‘This is not a new or revolutionary idea.’:[https://semver.org/]<)

	\1/
	choose `2021.2.0` instead of `2021.2`.
	^^^^^^ (по моему ощущению слово `choose` не очень подходит)

	\3/
	the version that fixes the major version [`2021.2`]
	^^^^^ (the major version is `2021`,
	here should be ‘main version’)
	\1/
	those fixing bugs in the major version
	^^^^^^^^^^^^^
	in the same month as the major one
	^^^^^
	(аналогично, здесь ‘major’ не уместно)

	\2/
	usually these are small utilities, e.g., command line tools
	^^^^ (в исходном тексте имеется в виду другое)

	\1/
	this strategy is followed by JetBrains [https://www.jetbrains.com/...]
	(некорректная ссылка, должно быть например:
	this strategy is ‘followed by JetBrains’[https://www.jetbrains.com/...]
	)

	\1/
	'Thus, YearVer (with versions like `YYYY.X` and `YYYY.X.Z`) considers 3 choices'{...}
	^ ^
	(сломано форматирование [и ещё в паре мест парные кавычки ‘ и ’ заменены на '])

	\2/
	For bug-fixing projects
	^^^^^^^^^^^^^^^^^^^ (не соответствует по смыслу оригиналу)

	\1/
	Of course, YearVer can be viewed as a special case of CalVer
	^ (я бы добавил ‘But’ в начало)
	```

	Итого: 14 баллов.

	[Сам перевод можно посмотреть по ‘этой ссылке’[https://gist.githubusercontent.com/alextretyak/b3e64d11afc832410ebea4b3a3d0d869/raw/02d3b9f622e20b85e137a4dce3db499ab5fd018f/tran.su.pq.txt].]

	[[Стоимость перевода: 4050 ₽.]]
	}

	В заключение [процесса перевода] осталось проделать кропотливую работу по «слиянию» трёх полученных переводов в один текст, выбрав лучшие варианты перевода каждого предложения и каждого термина/понятия.


	‘А почему «древопись»?’{Если представить дерево как структуру данных [в программировании], то действительно не очень понятно, как «древопись» с ним соотносится. Но если посмотреть на обычные деревья... Попробуйте на листе бумаги провести вертикальную черту — это ствол дерева, и это ваш текст [абзац или просто предложение]. Теперь нужно идти снизу вверх и дойдя до первого блока скрытого текста следует сделать ответвление (влево или вправо {можно чередовать: первый блок скрытого текста — ответвление влево, второй — вправо, третий — опять влево и т.д.}). Затем раскрываем первый блок скрытого текста [нижняя ветвь дерева]. Он может состоять либо из простого текста, либо содержать в себе другие блоки скрытого текста, соответствующие подветвям ~‘д’е~‘рева’. Потому и «~‘древо’пись».[[[В принципе, классический спойлер также можно считать формой «древописи».]]]

	‘А в чём отличие от классических спойлеров (вроде этого)?’{
	«Древопись» — это блоки скрытого текста внутри абзаца.
	А классический спойлер — это сам по себе отдельный абзац {но который, также как и блок скрытого текста «древописи», может содержать в себе несколько абзацев}.
	}
	[[[
	> Чем отличается «древопись» от «древотекста»?
	< «Древопись» — это технология письменности, а «древотекст» — это текст, написанный по этой технологии.
	]]]}
	><‘Н(1)‘Year-Based Versioning
	(YearVer)’’



	The key idea behind YearVer is to denote versions in the following formats: `YYYY.M`, `YYYY.N`, `YYYY.N.n` or `YYYY.M.n` {
	`YYYY` is the year
	`M` is the month (1 to 12)
	`N`/`n` is the version number (starting with 1)
	}.


	If you need 3 numbers separated by full stops [e.g. as in npm {
	```
	npm ERR! Invalid version: "2021.2"
	```
	>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
	the version number can only be like `\d+\.\d+\.\d+`’
	}], then simply use `2021.2.0` instead of `2021.2`.


	Additional versions published in the same month or {{

	For example, if you choose the first strategy, then version `2021.2.1` would denote ‘an additional/new version released in the same month as the core version [i.e. in February]’, and if you choose the second strategy, then this version would denote ‘a version that fixes bugs in the core version [`2021.2`] {in this case, core version `2021.2.1` might be released in another month}’.

	The second strategy allows using the second digit in the version number as index [of the version released in the corresponding year] instead of month. For example, this strategy is adopted[https://www.jetbrains.com/clion/download/other.html] by JetBrains.

	‘Thus, YearVer (i.e. version formats `YYYY.X` and `YYYY.X.Z`) provides you with 3 options’{
	1. For projects without bugfixes, `X` is the month in which this version was released and `Z` is the number of an additional/new version released in the same month {however, it is supposed that you don't release several new versions within a month}.
	2. For projects with bugfixes, `X` is the month in which this version was released and `Z` is the number of a bugfix version [that might be released in another month] resolving bugs in version `YYYY.X` or `YYYY.X.(Z-1)`.
	3. Similar to option 2, except that `X` is not a month, but an index [starting with 1] within the corresponding year. [This strategy is adopted by JetBrains.]
	}

	}} released to fix bugs in the core version {make sure to choose the strategy that best suits your project {in certain projects {smaller ones, such as command-line tools [and those that can be tested by almost 100%]}, each version can be (or must be) without bugfixes [{it's quite obvious that such projects don't need bugfix versions}]}} should be denoted as `2021.2.1`, `2021.2.2`, and so on.


	‘What's wrong with SemVer?’{
	SemVer[https://semver.org] is nice for versions below 1.0.0 or certain types of projects, but many SemVer principles, including how to increase the major version number, seem questionable. For example, if you change the name of an API function, would it be enough to increase the major version number?

	Other disadvantages of SemVer are described here[https://sedimental.org/designing_a_version.html <- https://calver.org].
	}


	‘What's wrong with CalVer?’{
	Its specification is too vague.
	However, YearVer can be considered a subset of CalVer[https://calver.org].
	}


	If you want to provide a feedback, please submit a ‘GitHub request ’[https://github.com/yearver/yearver/issues].
	><‘Н(1)‘Year-based versioning
	(YearVer)’’



	The idea of YearVer is to assign version numbers in the format of `YYYY.M`, `YYYY.N`, `YYYY.N.n`, or `YYYY.M.n` {
	`YYYY` is the full year
	`M` is the month (a number from 1 to 12)
	`N`/`n` is an incremented 1-based number
	}.


	If you need 3 numbers separated by a dot [like in npm {
	```
	npm ERR! Invalid version: "2021.2"
	```
	>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
	the version number can only be like `\d+\.\d+\.\d+`’
	}], choose `2021.2.0` instead of `2021.2`.


	Additional versions published in the same month, or {{

	This means that when choosing the first strategy, the version number `2021.2.1` means 'an additional/new version released in the same month as the major one [i.e., in February]', while in the second strategy, the same version number means 'the version that fixes the major version [`2021.2`] {also, the version `2021.2.1` itself may not have necessarily been released in February}'.

	The second strategy allows the second digit in the version number to be an incremented number [representing a version within the given year], instead of the month. For example, this strategy is followed by JetBrains [https://www.jetbrains.com/clion/download/other.html].

	'Thus, YearVer (with versions like `YYYY.X` and `YYYY.X.Z`) considers 3 choices'{
	1. For error-free projects, `X` stands for the month of the given version release, and `Z` stands for the additional/new version number in the same month {however, it is recommended to release new versions no more than once a month}.
	2. For bug-fixing projects, `X` stands for the month of the given version release, and `Z` is the version number [not necessarily released in the same month] that fixes the errors of the `YYYY.X` or `YYYY.X.(Z-1)` version.
	3. Similar to choice 2, only `X` is not the month, but an incremented 1-based number within the corresponding year. [JetBrains' strategy.]
	}

	}} those fixing bugs in the major version {you should decide and choose the most appropriate strategy depending on your project {there are projects {usually these are small utilities, e.g., command line tools [and projects having nearly 100% code coverage]} each version of which should/can be error-free [{obviously, these projects do not need bug-fixing versions}]}}, shall be numbered `2021.2.1`, `2021.2.2`, and so on.


	‘What's wrong with SemVer?’{
	SemVer [https://semver.org] works well for versions below 1.0.0 and for certain project types. However, many SemVer provisions raise questions, including the condition of the major version increment. For example, if you change the name of an API function, will that be enough to increase the major version?

	You can find other arguments against SemVer here[https://sedimental.org/designing_a_version.html <- https://calver.org].
	}


	‘What's wrong with CalVer?’{
	The CalVer specification is too vague {calver.org fails to give any specific recommendations on a calendar versioning scheme to choose; it simply describes the schemes already used in various projects, without highlighting them in any way}.
	Of course, YearVer can be viewed as a special case of CalVer[https://calver.org].
	}


	If you'd like to provide feedback, please add a ‘New issue on GitHub’[https://github.com/yearver/yearver/issues].
	><'N(1)' Year-based versioning
	(YearVer)’’



	The idea of YearVer is to specify version numbers in the form of `YYYY.M`,` YYYY.N`, `YYYY.N.n` or` YYYY.M.n` {
	`YYYY` is a year
	`М` is a month (any number from 1 to 12)
	`N`/`n’ is a sequential number (starting from 1)
	}.


	If you need 3 numbers separated by a dot [for example, as in npm {
	```
	npm ERR! Invalid version: "2021.2"
	```
	>[https://stackoverflow.com/a/27543014/2692494 <- google:‘npm ERR! Invalid version’]:‘
	the version number can only be like `\d+\.\d+\.\d+`’
	}], you can use `2021.2.0` instead of` 2021.2`.


	Additional versions published in the same month, or {{

	This means that, when choosing the first strategy, the version, for example, `2021.2.1` means 'an additional/new version released in the same month as the main one [i.e. in February]', and when choosing the second strategy, the same version number means ‘a version that fixes the major version [`2021.2`] {though the version` 2021.2.1` itself does not have to be released in February}'.

	When choosing the second strategy, it is allowed to use the second digit of the version number as a sequential number [of the version in the corresponding year], and not as a month number. Such a strategy is used by [https://www.jetbrains.com/clion/download/other.html], for example, JetBrains.

	'Thus, YearVer (designating a version in the form of `YYYY.X` and` YYYY.X.Z`) has 3 choices'{
	1. For error-free projects, the number `X` stands for a month number in which the given version was released, and the `Z` stands for an additional/new version number in the same month {however, it is recommended to release new versions no more than once a month}.
	2. For projects that allow bug-fixing, the number `X`is the month number in which the version was released, and `Z` is the version number [not necessarily released in the same month] that fixes the errors of the version `YYYY.X` or `YYYY.X.(Z-1)`.
	3. Similarly to par. 2, except for `X`, that does not stand for a month number, but a sequential number [starting from 1] within the corresponding year. [JetBrains strategy.]
	}

	}} fixing the bugs of the main version {you should decide and choose the most appropriate strategy depending on the project {there are projects {usually small in size, whereas in terms of the form they are usually command line utilities [and projects that can be covered by tests almost by 100%]} where each version must/can be bug-free [{obviously, such projects do not need bug-fixing versions}]}}, should be designated as `2021.2.1`, `2021.2.2`, etc.


	'What's wrong with SemVer?' {
	SemVer[https://semver.org/lang/ru/] is a good option for versions below 1.0.0 or for some types of projects, however many SemVer provisions raise questions, including the condition of raising the major version. For example, if you change the name of an API function, is that enough to increase the major version?

	You can find other arguments against SemVer here[https://sedimental.org/designing_a_version.html <- https://calver.org].
	}


	'What's wrong with CalVer?'{
	The specification is too vague.
	However, YearVer can, of course, be considered a special instance of CalVer[https://calver.org].
	}


	If you would like to share your feedback, please submit a 'GitHub Request'[https://github.com/yearver/yearver/issues].