Discussing glossary and style guide on translation

[another-guy]

Обсуждаем здесь любые вопросы, пожелания и предложения, связанные с руководством по переводу, включая перевод терминов и слов.

[another-guy]

• Word "bug" should definitely not be translated as "error" to Russian. Suggestion: дефект (similarly to "defect" which is close to "bug"), or баг which is informal, but absolutely omni-present and understood by everyone.

• Word "reuse" to only be translated as "повторное использование" rather than "переиспользование" which can not be found in vocabularies (gramota.ru, google search).

  Here's a related quote from an online source:

  Правильный русский эквивалент сравнительно нового термина
  «reusability» — «возможность повторного использования» или, что
  короче, «повторная используемость» (этот термин применяется к
  программному обеспечению). Однако у многих программистов в ходу
  оказался неправильные переводы «переиспользуемость» или
  «переиспользование». Действительно, одно из многих значений
  приставки «пере» «повторение действия заново, еще раз или иначе»
  (переделать, перестроить). Но в данном случае в языке уже есть слово
  «недоиспользование», что заставляет понимать «переиспользование»
  как его антоним, противоположность. То есть неправильно
  трактовать значение приставки «пере» — как чрезмерность,
  излишество использования (по аналогии с переплатить, перезреть),
  что, конечно, дезориентирует читателя или слушателя.

Any thoughts on that?

[another-guy]

@lex111 your input would be valuable on this one since you're authoring the TRANSLATION.md file (BTW, thanks for putting it together!)

Also, would we prefer to have a separate Git issue per word/term being discussed when necessity arises?

[lex111]

• Word "reuse" to only be translated as "повторное использование" rather than "переиспользование" which can not be found in vocabularies (gramota.ru, google search).

It's true this word is not and will be in the dictionaries, but it is still used and is not something grammatically wrong...

I will mention that there is such a useful dictionary - Multitran. https://www.multitran.ru/c/M.exe?l1=1&l2=2&s=reuse

Also, would we prefer to have a separate Git issue per word/term being discussed when necessity arises?

Agree, let there be one issue, where we will discuss the recommendations on translation, fine?

[another-guy]

Thanks for the reference to Multitran. I can rollback a commit regarding this word then (see PR).

[lex111]

Думаю, уместнее всего здесь писать на русском, предлагаю также добавить в файл ссылку на этот словарь.

Нужно определиться с тем как переводить props, в русском переводе Vue, данный термин переводится входные параметры (https://ru.vuejs.org/v2/guide/components-props.html)

[another-guy]

Мои пять копеек это поставить вопрос чуть иначе: стоит ли сейчас переводить props вообще. Я не живу в русско-говорящей стране, поэтому не знаю, что в разговорном обиходе для props.

Варианты:

• транслитерировать как проп(с?) -- гадость;
• перенять входные параметры как во Vue -- мне не нравится, потому что это далеко от дословного input parameters и усложнит обратный перевод (reverse lookup);
• оставить как props -- ни туда, ни сюда, но как мне кажется это меньшее из зол. Кстати, если потом определиться с хорошим вариантом, будет легко сделать full text search и заменить во всех местах.

Имело бы смысл сделать опрос русскоязычных React программистов. Так могли бы понять, какой из вариантов наименее отталкивающий для общей массы. Но не думаю, что на это есть ресурсы.

Update. Окей, я погорячился с "пропсы -- гадость". Похоже, в таком варианте многие и правда пишут уже сейчас. Если устоялось, то можно его использовать

[gaearon]

Я в целом за пропсы. На практике так все по-моему и говорят.

[gaearon]

Про стиль: #6

[gaearon]

Надо определиться по поводу:

• refs — рефы?
• keys — ключи?
• reconciliation — можно оставить так, можно "согласование"
• render — отрисовка? рендер?

Меня очень беспокоит render потому что в реакте рендер не занимается реальной "отрисовкой" (конфликт с paint). Как раз-таки наоборот — весь рендеринг происходит перед коммитом и пейнтом. Про это и так уже по-айнглийски путаются. Я думаю, может просто оставить «рендеринг» и «рендериться»? Более абстрактно и тогда мне кажется не так легко сбиться.

В качестве проблемного предложения — "Effects run after every render, but they don't block the paint." Если render отрисовка, то это превращается в неправильную тавтологию.

[ai]

Мне пока тоже кажется, что «рендер» лучшая вещь:

1. Мы говорим не о каком-то шаге, а о конкретном методе конкретного фреймворка.
2. Транслитированый «рендер» лучше render, так как его легкче склонять и он лучше вписывается в язык (ну и раскладку переключать не надо).
3. Я думаю многие кто используют функцию render не думаю, что это именно отрисовка (в значении прямого перевода слова).

Хотя если кто-то предложит что-то интереснее, то лучше конечно же заменить.

В рамках безумного лингофутуризма — «сборка» 😈

[gaearon]

Будешь смеяться, но он изначально назывался structure в древней внутренней версии 2011 года.

[gaearon]

Еще стоит иметь в виду, что со временем классы отойдут на второй-третий план, и название метода перестанет мелькать. По смыслу мы будем каждый раз говорить о «выполнении» функции.

[pepelsbey]

Если не терять контекста (мол, мы в Реакте), то всегда будет понятно, что такое «рендер».

Если в общем, я бы шёл по тропинкам, которые прокладывает сообщество. То есть буквально: послушать топовые русскоязычные доклады по Реакту и записать, как там говорят. Это будет настоящая документация.

[gaearon]

Тогда думаю рендер и рендеринг будет, но будет хорошо, если кто-то уточнит.

[gaearon]

Render: #9

[neustroev]

Привет! 👋
Бегло просмотрел /tutorial/tutorial.html - у меня больше вопросов, чем решений, но подумал, что все равно стоит их задать:

• feature - если есть "баг", то должна быть и "фича"? :)
• to mutate, его производные (immutability, "мутабельность", "изменяемость"?) и отличие от to change ([из]менять), если таковое необходимо?
• lifting state - устойчивое выражение в контексте реакта, если я правильно понимаю, поэтому, наверное, нужен аналог какой-то?

[verkholantsev]

Update. Окей, я погорячился с "пропсы -- гадость". Похоже, в таком варианте многие и правда пишут уже сейчас. Если устоялось, то можно его использовать

Я в целом за пропсы. На практике так все по-моему и говорят.

Может быть все-таки дать шанс термину «свойства»? Есть у него какие-то отрицательные стороны?

[gaearon]

Есть у него какие-то отрицательные стороны?

Думаю, что да. У «свойств» есть две проблемы:

• Properties это тоже свойства. (Object properties)
• В реакте компонент владеет своим состоянием, а пропсы получает от родителя. Но «свойство» происходит от «свой». Неизбежна путаница с традиционным OO-подходом, где каждый объект распоряжается своими свойствами, и их можно get и set. Реакт избегает этой проблемы, искажая слово в английском.

[lex111]

Как я заметил по текстам и докладам, в контексте React под рендером и отрисовка - одно и то же (имеется в виду сам процесс, а не название функции). И даже если говорят рендерит, то в целом имеют в виду то же самое — отрисовывает (и его производные).

Если посмотреть по гуглу:

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

Про видео, что мне приходит в голову: @xanf в своём докладе чаще даже упоминает немного отличающиеся термин — перерисовка, похожий на отрисовку вариант.

И как мне показалось, рендер используется, когда имеют в виду процесс в браузере, а отрисовку (или перерисовку) — для отображения, вывода, визуализации [компонента]. И судя по всему так и есть, учитывая упоминание paint в документации (3 раза), поэтому я бы настаивал на использовании именно отрисовки, а рендеринг — в специфичных случаях. И мне непонятно на самом деле по уже принятому PR, что используем, когда в документации упоминается render, всё-таки отрисовку?

P.S. Кстати по поводу reconciliation, всё тот же @xanf перевёл его как свёрка, насколько это верно и может этот вариант использовать, @gaearon?

[xanf]

reconcillation все таки "сверка" (без ё) :)
Мне этот термин нравится и не нравится одновременно. Не нравится как звучит, но нравится как "постороннему" от мира Реакта человеку сразу понятно что происходит

Про "перерисовку" / "отрисовку" - я за "отрисовку"
render = отрисовка
rerender = перерисовка

[verkholantsev]

Неизбежна путаница с традиционным OO-подходом

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

Реакт избегает этой проблемы, искажая слово в английском

Английский обладает большей гибкостью в этом случае — в нем подобные сокращения распространены шире.

С другой стороны очень близкое к «пропсы» «чипсы» вполне вошло в словари.

[lex111]

reconcillation все таки "сверка" (без ё) :)

Да, простите, глубокая ночь, пора идти спать :)

В качестве проблемного предложения — "Effects run after every render, but they don't block the paint." Если render отрисовка, то это превращается в неправильную тавтологию.

Тогда, render - используем транслитерацию, и далее отрисовку, верно?

[gaearon]

@lex111

С рендером усложняется ситуация, потому что на практике React всегда был синхронный, так что большой принципиальной разницы в путанице между render и paint в плане времени не было. Но в ближайшие месяцы эта разница появляется (в concurrent mode и с passive effects), и риск запутаться выше. Я думаю, что не стоит слишком ориентироваться на то, что эти два слова относительно взаимозаменяемы сегодня (а точнее, люди как правило не в курсе разницы).

Есть на самом деле несколько независимых процессов:

• Декларативный rendering и re-rendering in React (обычно значит выполнение функций и диффинг). Это самое частое значение в доке. Оно ничего с экраном не делает — и более того, в это время запрещено выводить что-то на экран. Это часть "render phase" — фазы когда Реакт не производит DOM мутаций.
• Императивная команда «вывести» дерево на экран, ReactDOM.render().
• Отрисовка браузером — painting.

Было бы здорово отделить первое по значению от следующих двух. Если два последних путаются, это не страшно.

Поэтому я за «рендер» про декларативную часть, «вывод» или «отображение» про ReactDOM.render, и «отрисовку» или «перерисовку» для browser paint.

[dmitrykrylov]

props - "атрибуты"?
Почему вообще React использует props а не attrs по аналогии с html терминологией?

[gaearon]

Атрибуты кстати было бы ок, если остальные не против. Тоже думал но забыл )

[gaearon]

Есть маленький caveat в том что не все JSX-атрибуты становятся пропсами. Например <div ref={foo} />, ref это атрибут но не проп. Потому что он резервирован реактом.

[GreLI]

«Прибраться». Как Firefox при установке: «немного прибираемся…».

[sqts]

@everdimension Да, я тоже об этом думал уже. Особенно в заголовке "Clean up effect", эффекты подчистки/эффекты с подчисткой и тд звучит коряво. А отменяемые эффекты / эффекты с отменой, звучит довольно понятно и адекватно.

[gaearon]

Отменить бывает как cancel а бывает как revert. Тут смысл больше revert, но люди могут понять как cancel.

[gaearon]

Освобождение эффекта?

[gaearon]

Эффект с уборкой 😄

[dpatrikeev]

На нашел эти слова в таблице соглашений по переводу. Подскажите, пожалуйста, как их лучше перевести.
prevent default
syntetic event
listeners
ON/OFF
refer

[gaearon]

prevent default

смотри в https://developer.mozilla.org/ru/docs/Web/API/Event/preventDefault
синтетическое событие
слушатели

остальное без контекста не понятно

[sqts]

@gaearon Да, согласен, в этом смысле может запутать людей. Может тогда отключение эффекта?

[gaearon]

Давайте cleanup обсудим тут #87

[lex111]

слушатели

Обработчики, может быть? web-standards-ru/dictionary#236 (comment)

[pavelkeyzik]

Что по поводу "consumers"? Пока нашёл только 2 варианта:
"consumers" -> "консьюмеры"
"consumers" -> "потребитель контекста"

[ntishkevich]

Что по поводу "consumers"? Пока нашёл только 2 варианта:
"consumers" -> "консьюмеры"
"consumers" -> "потребитель контекста"

А как насчет:
"consumer" -> потребитель
"consumers" -> потребители
"producer" -> поставщик/ производитель
"producers" -> поставщики /производители

Например, в java комьюнити(особенно когда речь заходит про JMS) используют консьюмеры и продьюсеры, не переводя их на русский.

[theghostbel]

Не всегда хватает соглашения по переводу. В веб-стандартах тоже не так много специфичных слов.

• 1. snapshot - снепшот? слепок?
• 2. view - вид? представление?
• 3. snapshot of the platform view hierarchy - платформо-зависимый слепок дерева представлений? снепшот вью специфичный для платформы в виде дерева?
• 4. pure JavaScript objects - чистые JavaScript объекты?

[pavelkeyzik]

@ntishkevich Я тут поэтому и спросил. Просто сейчас у нас "reducers" переводятся как "редьюсер" и в основном я на слуху всегда "редьюсер", а не перевод. Так вот может у нас такая же ситуация и с консьюмерами? Говоря "консьюмер" я больше понимаю о чём речь, чем, если бы сказали мне "потребитель". Главное прийти к какому-то одному выводу, чтобы переводы совпали 😄

[ntishkevich]

@pavelkeyzik Появилась идея выхода из ситуации, указать следующим образом при первом упоминании этого слова в тексте:
продьюсер (producer – буквально "поставщик")
консьюмер (consumer – буквально "потребитель")

Но тут я вспомнил еще о provider, который также можно переводить как поставщик, поэтому мне кажется, что вариант с продьюсером и консьюмером неплох

[RinatRezyapov]

• 1. snapshot - снепшот? слепок?

Как вариант snapshot - снимок

Если не получается найти варианты переводов можно воспользоваться сервисом https://context.reverso.net/ Сервис ищет перевод в контексте.

Click this button to copy the current snapshot to the clipboard.
Эта кнопка копирует полученный снимок в буфер обмена.

[everdimension]

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

Надо ли вообще переводить Context.Consumer?
Описан ли какой-то гайд про то, когда стоит переводить термин, а когда нет?

Например, для англоговорящей аудитории метод .map может объясняться через обычное слово "map", но в русской документации перевод метода ни к чему, и в пояснении легко обойтись общими словами.

Идея @ntishkevich не переводить, но транслитерировать такие слова мне нравится. Но есть нюанс: документация — не книга, поэтому понятие "первое упоминание" для читателя может не существовать.

Но возможно это и не страшно — для читателей переводов не в новинку оперировать терминами, не зная происхождение слова. Как тот же "рендер", например.

[sompylasar]

Но есть нюанс: документация — не книга, поэтому понятие "первое упоминание" для читателя может не существовать.

Первое упоминание в каждой статье (трудно поддерживать консистентность) или может существовать отдельная страница "глоссарий" со всеми терминами.

Кстати, тут у Википедии можно позаимствовать: первое упоминание термина на странице — это ссылка на другую страницу про этот термин (сейчас даже сделали всплывающие куски таких страниц, можно ограничиться этим).

[styopaiv]

А что насчет diff, diffing algorithm? Алгоритм сравнения, diff-алгортим?

[another-guy]

Закрываю issue. На неё всё ещё можно ссылаться, но не предвижу больших обсуждений. Для всех новых терминов будем открывать отдельные issue, как это уже не раз происходило.