You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Discussing glossary and style guide on translation #4
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» — «возможность повторного использования» или, что
короче, «повторная используемость» (этот термин применяется к
программному обеспечению). Однако у многих программистов в ходу
оказался неправильные переводы «переиспользуемость» или
«переиспользование». Действительно, одно из многих значений
приставки «пере» «повторение действия заново, еще раз или иначе»
(переделать, перестроить). Но в данном случае в языке уже есть слово
«недоиспользование», что заставляет понимать «переиспользование»
как его антоним, противоположность. То есть неправильно
трактовать значение приставки «пере» — как чрезмерность,
излишество использования (по аналогии с переплатить, перезреть),
что, конечно, дезориентирует читателя или слушателя.
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...
Мои пять копеек это поставить вопрос чуть иначе: стоит ли сейчас переводить props вообще. Я не живу в русско-говорящей стране, поэтому не знаю, что в разговорном обиходе для props.
Варианты:
транслитерировать как проп(с?) -- гадость;
перенять входные параметры как во Vue -- мне не нравится, потому что это далеко от дословного input parameters и усложнит обратный перевод (reverse lookup);
оставить как props -- ни туда, ни сюда, но как мне кажется это меньшее из зол. Кстати, если потом определиться с хорошим вариантом, будет легко сделать full text search и заменить во всех местах.
Имело бы смысл сделать опрос русскоязычных React программистов. Так могли бы понять, какой из вариантов наименее отталкивающий для общей массы. Но не думаю, что на это есть ресурсы.
Update. Окей, я погорячился с "пропсы -- гадость". Похоже, в таком варианте многие и правда пишут уже сейчас. Если устоялось, то можно его использовать
Я в целом за пропсы. На практике так все по-моему и говорят.
Reacted by Heegiiny, Igor Soloydenko, Evgenia Polozova, Aidar Ibatullin, Artem Golovin, avocadowastaken, Ivan Babak, Alexandr Kizilow, Vlad Derzhavin, Dzhamik Karimov and 1 more
reconciliation — можно оставить так, можно "согласование"
render — отрисовка? рендер?
Меня очень беспокоит render потому что в реакте рендер не занимается реальной "отрисовкой" (конфликт с paint). Как раз-таки наоборот — весь рендеринг происходит перед коммитом и пейнтом. Про это и так уже по-айнглийски путаются. Я думаю, может просто оставить «рендеринг» и «рендериться»? Более абстрактно и тогда мне кажется не так легко сбиться.
В качестве проблемного предложения — "Effects run after every render, but they don't block the paint." Если render отрисовка, то это превращается в неправильную тавтологию.
Reacted by Artem Golovin, Igor Soloydenko, Alexandr Kizilow and Vlad Derzhavin
Еще стоит иметь в виду, что со временем классы отойдут на второй-третий план, и название метода перестанет мелькать. По смыслу мы будем каждый раз говорить о «выполнении» функции.
Reacted by Aidar Ibatullin, Ivan Babak, Anton Kosykh and Vlad Derzhavin
Если не терять контекста (мол, мы в Реакте), то всегда будет понятно, что такое «рендер».
Если в общем, я бы шёл по тропинкам, которые прокладывает сообщество. То есть буквально: послушать топовые русскоязычные доклады по Реакту и записать, как там говорят. Это будет настоящая документация.
Reacted by dan, Artem Golovin, avocadowastaken, Ivan Babak and Dzhamik Karimov
Reacted by Aidar Ibatullin, Evgenia Polozova, Artem Golovin and Ivan Babak
@ntishkevich Я тут поэтому и спросил. Просто сейчас у нас "reducers" переводятся как "редьюсер" и в основном я на слуху всегда "редьюсер", а не перевод. Так вот может у нас такая же ситуация и с консьюмерами? Говоря "консьюмер" я больше понимаю о чём речь, чем, если бы сказали мне "потребитель". Главное прийти к какому-то одному выводу, чтобы переводы совпали 😄
@pavelkeyzik Появилась идея выхода из ситуации, указать следующим образом при первом упоминании этого слова в тексте: продьюсер (producer – буквально "поставщик") консьюмер (consumer – буквально "потребитель")
Но тут я вспомнил еще о provider, который также можно переводить как поставщик, поэтому мне кажется, что вариант с продьюсером и консьюмером неплох
Вообще я возможно упустил это обсуждение, но мне кажется, что надо стараться переводить термины по минимуму. Каждый новый придуманный перевод это почти как новая строка кода, которую нужно поддерживать.
Надо ли вообще переводить Context.Consumer?
Описан ли какой-то гайд про то, когда стоит переводить термин, а когда нет?
Например, для англоговорящей аудитории метод .map может объясняться через обычное слово "map", но в русской документации перевод метода ни к чему, и в пояснении легко обойтись общими словами.
Идея @ntishkevich не переводить, но транслитерировать такие слова мне нравится. Но есть нюанс: документация — не книга, поэтому понятие "первое упоминание" для читателя может не существовать.
Но возможно это и не страшно — для читателей переводов не в новинку оперировать терминами, не зная происхождение слова. Как тот же "рендер", например.
Reacted by Ivan Babak, Nick Tishkevich and Mr Robot
Но есть нюанс: документация — не книга, поэтому понятие "первое упоминание" для читателя может не существовать.
Первое упоминание в каждой статье (трудно поддерживать консистентность) или может существовать отдельная страница "глоссарий" со всеми терминами.
Кстати, тут у Википедии можно позаимствовать: первое упоминание термина на странице — это ссылка на другую страницу про этот термин (сейчас даже сделали всплывающие куски таких страниц, можно ограничиться этим).
Закрываю issue. На неё всё ещё можно ссылаться, но не предвижу больших обсуждений. Для всех новых терминов будем открывать отдельные issue, как это уже не раз происходило.
Activity
another-guy commentedon Feb 8, 2019
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:
Any thoughts on that?
another-guy commentedon Feb 8, 2019
@lex111 your input would be valuable on this one since you're authoring the
TRANSLATION.mdfile (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 commentedon Feb 8, 2019
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
Agree, let there be one issue, where we will discuss the recommendations on translation, fine?
another-guy commentedon Feb 8, 2019
Thanks for the reference to Multitran. I can rollback a commit regarding this word then (see PR).
[-]TRANSLATION.md[/-][+]Discussing glossary and style guide on translation[/+]lex111 commentedon Feb 8, 2019
Думаю, уместнее всего здесь писать на русском, предлагаю также добавить в файл ссылку на этот словарь.
Нужно определиться с тем как переводить props, в русском переводе Vue, данный термин переводится входные параметры (https://ru.vuejs.org/v2/guide/components-props.html)
another-guy commentedon Feb 8, 2019
Мои пять копеек это поставить вопрос чуть иначе: стоит ли сейчас переводить props вообще. Я не живу в русско-говорящей стране, поэтому не знаю, что в разговорном обиходе для props.Варианты:транслитерировать как проп(с?) -- гадость;перенять входные параметры как во Vue -- мне не нравится, потому что это далеко от дословного input parameters и усложнит обратный перевод (reverse lookup);оставить как props -- ни туда, ни сюда, но как мне кажется это меньшее из зол. Кстати, если потом определиться с хорошим вариантом, будет легко сделать full text search и заменить во всех местах.Имело бы смысл сделать опрос русскоязычных React программистов. Так могли бы понять, какой из вариантов наименее отталкивающий для общей массы. Но не думаю, что на это есть ресурсы.Update. Окей, я погорячился с "пропсы -- гадость". Похоже, в таком варианте многие и правда пишут уже сейчас. Если устоялось, то можно его использовать
gaearon commentedon Feb 8, 2019
Я в целом за пропсы. На практике так все по-моему и говорят.
gaearon commentedon Feb 8, 2019
Про стиль: #6
gaearon commentedon Feb 8, 2019
Надо определиться по поводу:
Меня очень беспокоит render потому что в реакте рендер не занимается реальной "отрисовкой" (конфликт с paint). Как раз-таки наоборот — весь рендеринг происходит перед коммитом и пейнтом. Про это и так уже по-айнглийски путаются. Я думаю, может просто оставить «рендеринг» и «рендериться»? Более абстрактно и тогда мне кажется не так легко сбиться.
В качестве проблемного предложения — "Effects run after every render, but they don't block the paint." Если render отрисовка, то это превращается в неправильную тавтологию.
ai commentedon Feb 8, 2019
Мне пока тоже кажется, что «рендер» лучшая вещь:
renderне думаю, что это именно отрисовка (в значении прямого перевода слова).Хотя если кто-то предложит что-то интереснее, то лучше конечно же заменить.
В рамках безумного лингофутуризма — «сборка» 😈
gaearon commentedon Feb 8, 2019
Будешь смеяться, но он изначально назывался structure в древней внутренней версии 2011 года.
gaearon commentedon Feb 8, 2019
Еще стоит иметь в виду, что со временем классы отойдут на второй-третий план, и название метода перестанет мелькать. По смыслу мы будем каждый раз говорить о «выполнении» функции.
pepelsbey commentedon Feb 8, 2019
Если не терять контекста (мол, мы в Реакте), то всегда будет понятно, что такое «рендер».
Если в общем, я бы шёл по тропинкам, которые прокладывает сообщество. То есть буквально: послушать топовые русскоязычные доклады по Реакту и записать, как там говорят. Это будет настоящая документация.
84 remaining items
sqts commentedon Feb 11, 2019
@gaearon Да, согласен, в этом смысле может запутать людей. Может тогда отключение эффекта?
gaearon commentedon Feb 11, 2019
Давайте cleanup обсудим тут #87
lex111 commentedon Feb 11, 2019
Обработчики, может быть? https://github.com/web-standards-ru/dictionary/issues/236#issuecomment-222292981
pavelkeyzik commentedon Feb 12, 2019
Что по поводу "consumers"? Пока нашёл только 2 варианта:
"consumers" -> "консьюмеры"
"consumers" -> "потребитель контекста"
ntishkevich commentedon Feb 12, 2019
А как насчет:
"consumer" -> потребитель
"consumers" -> потребители
"producer" -> поставщик/ производитель
"producers" -> поставщики /производители
Например, в java комьюнити(особенно когда речь заходит про JMS) используют консьюмеры и продьюсеры, не переводя их на русский.
theghostbel commentedon Feb 12, 2019
Не всегда хватает соглашения по переводу. В веб-стандартах тоже не так много специфичных слов.
pavelkeyzik commentedon Feb 12, 2019
@ntishkevich Я тут поэтому и спросил. Просто сейчас у нас "reducers" переводятся как "редьюсер" и в основном я на слуху всегда "редьюсер", а не перевод. Так вот может у нас такая же ситуация и с консьюмерами? Говоря "консьюмер" я больше понимаю о чём речь, чем, если бы сказали мне "потребитель". Главное прийти к какому-то одному выводу, чтобы переводы совпали 😄
ntishkevich commentedon Feb 12, 2019
@pavelkeyzik Появилась идея выхода из ситуации, указать следующим образом при первом упоминании этого слова в тексте:
продьюсер (producer – буквально "поставщик")
консьюмер (consumer – буквально "потребитель")
Но тут я вспомнил еще о
provider, который также можно переводить как поставщик, поэтому мне кажется, что вариант с продьюсером и консьюмером неплохRinatRezyapov commentedon Feb 12, 2019
Как вариант snapshot - снимок
Если не получается найти варианты переводов можно воспользоваться сервисом https://context.reverso.net/ Сервис ищет перевод в контексте.
everdimension commentedon Feb 12, 2019
Вообще я возможно упустил это обсуждение, но мне кажется, что надо стараться переводить термины по минимуму. Каждый новый придуманный перевод это почти как новая строка кода, которую нужно поддерживать.
Надо ли вообще переводить
Context.Consumer?Описан ли какой-то гайд про то, когда стоит переводить термин, а когда нет?
Например, для англоговорящей аудитории метод
.mapможет объясняться через обычное слово "map", но в русской документации перевод метода ни к чему, и в пояснении легко обойтись общими словами.Идея @ntishkevich не переводить, но транслитерировать такие слова мне нравится. Но есть нюанс: документация — не книга, поэтому понятие "первое упоминание" для читателя может не существовать.
Но возможно это и не страшно — для читателей переводов не в новинку оперировать терминами, не зная происхождение слова. Как тот же "рендер", например.
sompylasar commentedon Feb 12, 2019
Первое упоминание в каждой статье (трудно поддерживать консистентность) или может существовать отдельная страница "глоссарий" со всеми терминами.
Кстати, тут у Википедии можно позаимствовать: первое упоминание термина на странице — это ссылка на другую страницу про этот термин (сейчас даже сделали всплывающие куски таких страниц, можно ограничиться этим).
styopaiv commentedon Feb 13, 2019
А что насчет diff, diffing algorithm? Алгоритм сравнения, diff-алгортим?
another-guy commentedon Mar 13, 2019
Закрываю issue. На неё всё ещё можно ссылаться, но не предвижу больших обсуждений. Для всех новых терминов будем открывать отдельные issue, как это уже не раз происходило.