Перемен

[skip405]

TL;DR

Предлагаю нормализировать процесс перевода терминов. Я заметил, что заявленные принципы и подходы не всегда работают, а иногда и вовсе не подходят.

Приглашаю @pepelsbey @tachisis @meritt @marinintim @firefoxic @SelenIT отреагировать на то, что здесь написано. Если вы не видите своего имени в списке и вам есть что сказать, тоже говорите :)

---

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

При выборе варианта перевода приоритет будет отдан наиболее употребимому в профессиональной среде, либо исторически принятому (например, в типографике).

Какие я вижу проблемы в заявленных принципах:

Проблема 1. В каком порядке их применять?

Пример: разработчик Лена пытается добавить в словарь слово header. Как ей поступить: перевести его как хидер (именно этот вариант она часто слышит в профессиональной среде) или как шапка, который она тоже слышала, но не знает, откуда он, возможно из смежной сферы. Как узнать, какой вариант наиболее употребим? Какой «счётчик» должен являться для Лены авторитетным? Или, может, нужны оба варианта?

Проблема 2. Насколько вообще верно следовать мнению большинства и выносить это как принцип?

Если все пойдут и с крыши спрыгнут, ты тоже спрыгнешь? Если все сегодня «одевают варежки», а ты «надеваешь», то ты поступаешь плохо? Иными словами — насколько «правильным» является предложенный подход? Неужели уровень владения английским языком среднестатистического разработчика у нас в сфере такой высокий, что мы можем не ставить произнесение того или иного термина под сомнение и просто доверять всему, что мы слышим? Никакие компании не предлагают языковые курсы как бонус при найме, всё прям топчик у нас в сфере в плане английского?

Пример: разработчик Лена имеет C2 по инглишу и знает, что слово header произносится примерно как [хэдэр] (не [хидер]). Должна ли Лена игнорировать свои знания и просто принять, что она… часть меньшинства. И написать хидер просто потому, что никто её не понимает. Вернее понимают, но таких людей мало.

Проблема 3. Отсутствуют подходы, или хотя бы их упоминание, которые приняты в лингвистике (а мы-то здесь переводим, не?)

То есть, разработчик Лена должна посмотреть, как термин используется в проф. среде, потом прошерстить смежные сферы, а только потом (если захочется) может посмотреть перевод в словаре? Если да, то это проблема, если нет и словарями можно пользоваться, то см. проблема 1, поскольку Лена не знает, какой из принципов «важнее» и что применять за чем. Словарь говорит одно, народ — «другое».

Проблема 4. Предложенные подходы не подходят для терминов, которые появляются в данный момент.

Пример: вышла новая спецификация, массового использования терминологии из этой спецификации в проф. среде не может быть по определению. Если повезёт и смежная сфера есть, то ок, а если нет — что тогда делать разработчику Лене?

Плюсы текущего подхода писать не буду, они есть, но в данный момент фокус на проблемах.

Критикуешь — предлагай:

Решение проблем в изменении подхода. Предлагаю следующий алгоритм для перевода любого термина:

0. создать ишью в этом словаре
1. посмотреть/поискать исторически принятые варианты перевода (например в типографике), зависит от сферы, сайты любые, которые выглядят как достоверные
2. посмотреть, как это слово переводится в словарях (multitran, википедия, MDN или ещё какой-нить словарик, вроде Доки и тд. Нужен список «хороших» лингвистических ресурсов, которые позволят Лене перевести, и на которые она будет ссылаться предлагая перевод). Просто ссылка на словарь, это «подтверждение» должно являться критерием принятия варианта. Ждать резолюции в ишью, спорить, комбинировать, искать.
3. если пункты 1 и 2 не приводят к ярко-выраженным переводам, или этот перевод затрудняет понимание, или в комментариях к ишью тоже никто ничего хорошего не нашёл, то возможно нужна калька.

3.1. калька должна (вот прям должна должна) быть сделана, руководствуясь принятыми правилами практической транскрипции.

Для этого не нужно быть бакалавром «лингвистических наук», достаточно уметь находить звуки в табличке и выбирать из предложенных вариантов. То есть — точно так же, как мы смотрим на «исторически принятую терминологию», точно так же смотрим на «исторически принятую систему калькирования», если термин нужно калькировать.

Позволю себе процитировать начало статьи про английскую транскрипцию, для чего она предназначена:

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

Ничего не напоминает? Какие причины вообще могут быть для игнорирования этого? Это должно стать инструментом, помогающим переводить, причём для кальки и транскрибирования имён — единственным инструментом, потому что другие вообще не нужны.

4. (опционально) можно посмотреть, как этот термин используется в профессиональной среде и указать его «разговорный» вариант. Пример: разработчик Лена вполне может предложить такую статью: border — рамка, (разг. бордер). Опционально и без фанатизма. Если будут сложности — вообще убрать этот пункт.

Список отсортирован, менять местами пункты нельзя. Порядок важности, который мне видится хорошим:
исторически сложившееся → перевод → калька → без изменения (прям по-английски оставляем).

Плюсы предлагаемого подхода:

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

Минусы предлагаемого подхода:

• больше работы. Или нет. Как посмотреть :) А кто сказал, что должно быть легко?

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

Оффтопик:

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

[pepelsbey]

Мне кажется, что это предложение в корне меняет суть словаря. Это ни плохо, ни хорошо — это факт. Возможно, для такого словаря есть место и от него будет польза. Но лично мне будет сложно заниматься словарём с таким уровнем академичности и такими задачами. Как минимум, у нас мало людей с подходящей квалификацией, плюс это следующий уровень сложности и ответственности. Фиксировать тренды и задавать тренды — это очень разные вещи. Я уверен, что мы так или иначе влияем на сообщество своей работой, но делаем это мягче. И так, на мой взгляд, правильнее, чем искать «правду» в книгах и навязывать её сообществу.

[timmarinin]

Не очень понял, так сказать, ментион меня, но отмечу, что

а) на «правильность» транскрипции лично я обращаю примерно ноль внимания;
б) насильно заставить людей писать «шапка» вместо «хидер» не получится, и если условной Лене важнее понятность коммуникации, чем прескриптивизм, то…
в) всегда есть возможность писать термины, как считаете правильным, вне словаря, что повысит частотность предпочтительного варианта.