Перевод opensource.guide на русский

Привет! В этой задаче представлена информация о том, как производиться перевод opensource.guide (далее просто «OSG») и разные вещи, которые стоило бы знать.

Начнём со знакомства с OSG:

Что такое OSG?

OSG — это сборник качественных и мотивирующих статей-руководств про участие и создание open source проектов. Open source — сборное название проектов со свободными лицензиями и открытыми исходными кодами (а лучше сказать «материалами» так как, например, в случае с OSG, там в основном тексты).

Зачем его переводить?

Это действительно хороший вопрос, ведь многие из нас понимают, что участие в мировых open source проектах в большинстве случаев включает в себя использование английского языка, того же, в каком представлен OSG в оригинале.

Но, скорее всего, следовало бы посмотреть на это со стороны пользы такого перевода, ведь он может подтолкнуть русскоязычные сообщества к созданию и участию в таких проектах. Можно сказать, что та же википедия является open source сообществом: у них свободная лицензия CC, любой может вносить изменения и даже воспользоваться движком MediaWiki. Так что нужно оглядываться не на иностранное сообщество (хотя оно играет большую роль в Open Source), а на русскоязычное.

Как мы будем выполнять перевод здесь?

В проекте есть множество файлов, но важные перечислены в списке ниже.

План

Для начала, легенда (что значат эмодзи):

:bulb: Идея
:walking_man: Над файлом ведётся работа
:large_blue_circle: Задача доступна, но никто за неё не взялся
:stop_sign: Задача заблокирована, пока другая задача не решена
:round_pushpin: Задача готова, но нуждается в проверке
:ok: Задача завершена

Определяющие файлы

[x] :ok: Главная страница (_articles/ru/index.html) — завершена
[x] :round_pushpin: Данные локализации (_data/locales/ru.yml) — ожидает проверки

Статьи

[ ] :round_pushpin: How to Contribute to Open Source (_articles/ru/how-to-contribute.md) — нуждается в проверке #5
[ ] :round_pushpin: Starting an Open Source Project (_articles/ru/starting-a-project.md) — нуждается в проверке #6
[ ] :large_blue_circle: Finding Users for Your Project (_articles/ru/finding-users.md) — доступна
[ ] :large_blue_circle: Building Welcoming Communities (_articles/ru/building-community.md) — доступна
[ ] :large_blue_circle: Best Practices for Maintainers (_articles/ru/best-practices.md) — доступна
[ ] :large_blue_circle: Leadership and Governance (_articles/ru/leadership-and-governance.md) - доступна
[ ] :large_blue_circle: Getting Paid for Open Source Work (_articles/ru/getting-paid.md) — доступна
[ ] :large_blue_circle: Your Code of Conduct (_articles/ru/code-of-conduct.md) — доступна
[ ] :large_blue_circle: Open Source Metrics (_articles/ru/metrics.md) - доступна
[ ] :large_blue_circle: The Legal Side of Open Source (_articles/ru/legal.md) — доступна

Локализация

[ ] :bulb: Поиск подходящих цитат на русском языке — идея, блокируется

Есть проблема, потому что использование чьих-то цитат потребует нас спрашивать разрешение (для существующих цитат GitHub, скорее всего, уже получил разрешение).

Завершение

[ ] :stop_sign: Окончательные проверки — блокируется
- [ ] Все TODO решены
- [ ] Все FIXME решены
[ ] :stop_sign: Полноценное ревью — блокируется
[ ] :bulb: Проверить возможность использования ToC (Table of Contents) — идея

Как переводить?

Если вы хотите переводить файлы:

Вам необходимо будет сделать ответвление (форк) этого репозитория и создать в нём ветку относительно ветки ru (git checkout -b patch-1 ru). Подробная инструкция в задаче #3.

Вопросы касательно общего перевода решаются в разделе «Issues» тут, вопросы касательно перевода отдельного файла решаются в комментариях к запросу на слияние.

Ревью:

Вы можете проверять переводы других участников на ошибки. Для этого загляните в секцию запросов на слияние и выберите любой, перейдите в список изменённых файлов и посмотрите изменения. В комментариях к запросам чаще всего можно найти дифф-коммит (сравнение) с оригиналом.

Правила относительно переводов

Пока имеются следующие, но всегда можно создать новую задачу и обсудить.

Основные

Всегда используйте обычные правила относительно заглавных букв. Т.е. не стоит писать каждое слово с заглавной в заголовках: это англоязычный стиль, у нас такого нет
«Вы» всегда с маленькой. Кроме как, конечно, в начале предложений.
Не переводить бренды и названия. Например, GitHub, Git, Windows
Избегать по возможность написания «ваше», заменив его на «своё»
Использовать «русские» кавычки-ёлочки и лапки (в помощь композиционная клавиша (Compose) или раскладка Бирмана)
Использовать «ё» где можно. Несмотря на рекомендации по выборочному написанию, гадать, где её нужно ставить, а где нет — лишняя работа, как для пишущего, так и читателя
Если попадётся, то писать стрелки используя юникодовые символы (←, → и т.д.; не дефис и знак больше ->)
Текст должен звучать естественно (главное — не терять смысл и не создавать новый)

Перевод

«Open source» можно переводить как «открытые проекты» (под обсуждением)
«Contribution» — иногда «вклад» («Making a contribution»), а иногда «участие» («Contribution in a project»)
«Pull Request» → «запрос на слияние»
«Fork» → «Ответвление» (под обсуждением)
«Branch» → «Ветвь»
«Maintainer» → «Сопровождающие»
«Collaborator [of the repository]» → «Соавтор [репозитория]»
«Contributor» → «Участник»

После того, как всё будет готово

Как я говорил, будучи переводчиком в Discord:

Локализация — это постоянный процесс, она не заканчивается никогда. В какой-то момент у вас будет 100% переводов, но завершена она не будет: всегда найдутся ошибки и вещи, которые можно исправить и улучшить. Идеальной локализации, как и ПО, не существует, но шаг за шагом она будет улучшаться со временем.

Поэтому, предположительно, после готовности переводов в этом репозитории и последующим их слиянием с основным, мы сможем создавать запросы уже относительно основного.

Правда следует ли так делать? Ведь тогда мы потеряем возможность координации на основном для нас языке и создавать подобные задачи/вики с информацией. А можно просто продолжать работать над ответвлением, время от времени брать оттуда изменения и наоборот, отправлять наши изменения. Этот вопрос нужно будет решить.

@Sasha-Sorokin привет! Классно, что наконец кто-то взялся за перевод этого нужного проекта! На самом деле думал об переводе этого проекта, но всё никак не решался, поэтому готов предложить свою помощь в этом непростом деле.

Здравствуй, @lex111! Извиняюсь, что так затянул с ответом. Проект действительно воодушевляющий и необходимый, было бы здорово осуществить его перевод на русский — любая помощь крайне приветствуется!

Выше можно видеть список всех статей и их состояние. Если желаешь переводить — бери любую доступную, и, после перевода шапки, открой черновой запрос на слияние с ветвью ru этого репозитория, в котором можно будет следить за прогрессом и обсудить вопросы; либо можно открыть новую задачу, а по окончании уже запрос, как тебе удобнее. Если не хочешь переводить, то можно проверять и предлагать исправления в уже существующих переводах.

Для любых значительных вопросов и обсуждений желательно открывать новые задачи, чтобы другие могли легче найти принятые решения, однако простые вопросы можно обсуждать в запросах/задачах по переводу отдельных статей: сводки я всё равно постараюсь добавить сюда (см. заголовок «правила относительно переводов»).

@Sasha-Sorokin отлично, я хочу попробовать перевести, но пока я бы предложил определиться с переводом терминов. Есть словарь Веб-стандартов, в котором помимо прочего есть и рекомендуемый перевод терминов гита. Т.е, pull request/fork не переводятся, а пишутся по-русски - пулреквест и форк, соответственно. По поводу open source я бы точно так же поступил - использовал опенсорс, хотя открытые проекты - весьма неплохо и я видел, что так переводят, хотя и предлагаемый вариант тоже неплохо используется. Если уместна такая аналогия, то в соответствии с указанным выше словарем, frontend = фронтенд, то получается, например, фронтенд-разработчик, а не разработчик интерфейсов или что-то того.

Я видел словарь «веб-стандартов», но это скорее разговорная терминология, которую вряд ли можно и нужно применять в контексте литературы, или предлагаете «сабмитить коммиты» вместо «отправки изменений»? :)

В «фронтенд-разработчиками» это вполне уместно: у нас нет таких же ёмких слов. С Fork/Pull request мы можем достаточно описательно переводить их как «ответвление [от текущего репозитория]» и «запрос на слияние [с другой ветвью]» (или «объединение», глядя на «веб-стандарты»), мы ничего от этого не потеряем, и наоборот, получим вполне рабочий русский вариант.

О «фронтенд-разработчиках» вообще

«Разработчик интерфейсов» — это действительно не самоописываемый вариант и не охватывает всю область такого разработчика, помимо этого, его несложно спутать с «проектировщиком интерфейса». Если хочется более точного перевода, могу предложить для развлечения «разработчик клиентской части». Большинство работодателей, однако, предпочитают использовать в этом случае **английский вариант написания** «Frontend-разработчик», «Fullstack-разработчик» и т.д. Руководствуясь этим, такие термины как master, origin, upstream, в транскрипции не нуждаются, тот же master можно «обрамлять» — «ветвь „master“», `master`.

Взять случай из Discord: там есть HypeSquad, это бренд и мы его не переводили соответственно, но из-за названия в некоторых связанных строках присутствовало слово «hype», в случае чего мы использовали неологизм/заимствование «хайп», потому что сам Discord позволяет использовать разговорную речь и хотелось сохранить смысл и привязанность.

Примеры перевода «hype»

Говоря про Open Source

С «open source» в нашей команде был жаркий спор: одни предлагали использовать оригинальный «open source», другие «опенсурс», третьи вообще «проекты с открытым исходным кодом». Почему у меня, как у тогдашнего проверяющего (пруфридера), ко всем вариантам были замечания, по порядку:

В случае с «open source» мы оставляли оное «как есть» и честно, когда ты смотришь на это со стороны простого обывателя, тебе изначально приходит в голову мысль, что это какое-то название, это показалось неправильным (мы так никогда не делали)
Заимствование «опенсурс» вроде допустимо и выглядит весьма лаконично: тут ты не подумаешь о названии при чтении в предложении, но вот незадача — как самостоятельное слово в заголовке оно не годится: «Опенсурс — Discord»
Варианты «Проекты с открытым исходным кодом» и «открытое ПО» сразу вызывали недовольство: «ведь такие проекты не всегда про ПО, это могут быть различные руководства, или как у нас — открытый проект по переводу!» ~~мы ошибались~~

В конце концов, было принято использовать простое указание «открытости» — «открытые проекты», в зависимости от местонахождения строки. Это был самый логичный вариант и выглядел он весьма замечательно.

Лишь оглядываясь сейчас, глядя на типы принятых проектов, понятно, что вариант «проектов с открытым исходным кодом» был жизнеспособен, потому что Discord не принимает что-то кроме ПО и библиотек в рамках этой программы сообщества. Мы таких подробностей не знали, как и не было возможности запросить контекст, у компании по переводу такая возможность есть и они ей с радостью воспользовались (и в некоторых местах всё ухудшили :).

Однако, тогдашнее решение из Discord применимо здесь, достаточно немного пробежаться по первой статье OSG, чтобы это понять.

Заключение

Считаю, вышеописанного опыта достаточно, чтобы понять, чем я руководствуюсь на данный момент. Не очень хотелось бы видеть перевод «на коленке», больше нечто похожее на статьи в Википедии (но у нас уже есть готовое содержимое и это OSG не энциклопедия).

Резюмируя, можно записать так:

Везде, где возможно использовать более понятный перевод, следует использовать перевод, а не транскрипцию (~~«создать пуллреквест»~~ «создать запрос на слияние», ~~«открыть ишью»~~ «создать новую задачу»)
Для английских терминов без общепринятой и широко используемой транскрипции в литературе, таких как команды Git и название ветвей, лучше написать их на английском языке и уточнять что они значат в скобках или указывая тип («ветвь „master“», «master (основная ветвь репозитория)»)
Следовало бы избегать слишком формального стиля, чтобы статьи для новичков получались дружелюбные и менее техничные, но и не пренебрегать этим, безостановочно используя разговорные формы (~~«залейте скриншот, дропнув его в поле»~~ «загрузите скриншот, перетащив его в поле», ~~«запушьте коммиты»~~ «отправьте изменения»)
В некоторых случаях перевод желательно варьировать от местонахождения (контекста) оригинальной фразы (contribute: «внесите вклад», «примите участие»).

Что считаешь насчёт этого?

@Sasha-Sorokin здорово, у меня правда голова кругом, чтобы что-то внятное написать, но прочитал статью на ВК, - это впечатляет на самом деле, жаль только, что вот так вышло. По поводу ишью лучше всего почитать обсуждение, почему этот термин не переводился. P.S. у меня есть желание помочь, тем более последнее время занимаюсь переводами, но весьма плохо, к сожалению, так что боюсь, что окажусь бесполезным...

...вижу, что энтузиазм иссяк, попробую в этом месяце что-нибудь поделать, но насчет переводов терминов я по-прежнему за англицизмы, потом если что заменим, проще будет тем более. Как тебе такой вариант?

Я могу поучаствовать в переводе и пояснении контекста, но у меня большие проблемы с использованием данного инструмента

@tumani4 отлично, а проблемы с гитом?

@lex111 у кого иссяк? Я просто занимался несколькими проектами для себя, до OSG руки не доходили. Сейчас немного разгрузился, будем смотреть =)

Насчёт «англицизмов» всё ещё не уверен, мы не пишем техническую литературу… Проще для нас, не проще для читателя, особенно новичков в этом деле. Да и выглядеть это будет слишком неформально. Все аргументы были выше, я за использование понятных русских слов, где это возможно.

@tumani4 создал обсуждение #3, посмотри, если это поможет разобраться с инструментом, если что — мы тут :)

@Sasha-Sorokin извини, неверно выразился :(

https://github.com/Sasha-Sorokin/opensource.guide/issues/1#issuecomment-508295633 всё верно! Не могу разобраться с механизмом

Преобразовал свои переводы в отдельные запросы на слияние, если что, можно делать там ревью (оставлять комментарии прямо на изменениях):

how-to-contribute.md → #5 (к ревью →)
starting-a-project.md → #6 (к ревью →)

:warning: Так как из-за этого я также убрал свои коммиты из ветки ru и принудительно её обновил (aka «зафорспушил»), если вы делали изменения в локальном репозитории, необходимо выполнить перебазирование. Подробнее здесь →

:information_source: Также сделал ветку сравнений, в которой буду делать коммиты-сравнения (диффы) с оригиналом, чтобы было немного удобнее читать оригинал / перевод в две колонки (можно также оставлять комментарии к отдельным строкам, но лучше выносить их в запросы). В совсем ближайшее время к своим запросам скину ссылки на эти диффы.

...opensource не стоит переводить, а писать "опенсорс", хотя бы потому, что так не будет возможной путаницы между open-source project и open project. Конечно, можно возразить, что в данном контексте этой разницы не будет, но мало ли. Может пойти всё-таки пойти на такую вольность?

UPD: по аналогии с user script, можно перевести как пользовательский скрипт, или лучше не переводить - юзерскрипт, потому что смысл разный.

Похоже, У меня совсем нет времени заниматься переводом этого проекта. А также, не видно никакого интереса со стороны других русскоговорящих пользователей к ревью существующих переводов.

Поэтому я закрываю свой PR и архивирую этот форк. Если кто-то захочет заниматься русским переводом в будущем, может сам форкнуть основной репозиторий, либо перебазировать этот, а лучше просто вручную отобрать файлы переводов.

Спасибо всем, кто принимал участие в обсуждении.

brawaru / opensource.guide