Русскоязычная терминология

[Dale]

а неудобопроизносимый "фреймворк" можно заменить на "платформа"

Тоже плохо, IMHO. Термин "платформа" слишком заездили, причем совершенно неоднозначно. Intel и SPARC - платформы, Windows и Linux - платформы, .NET и Java - тоже платформы... Слово практически утратило смысл, его начали употреблять исключительно для эмуляции глубокомысленности. "Фреймворк" гораздо конкретнее, хоть и неблагозвучно. Но ведь привыкли к драйверам и трансляторам, не заменяем их "водителями" и "переводчиками". Глядишь, и "моки" с "тулчейнами" приживутся со временем.

[Dale]

Судя по толкованию на аглицкой вики, это типичная IDE

Не совсем так. Из опыта использования "тулчейнов" у меня нарисовалась такая картина: тулчейн обычно имеет интерфейс командной строки, например, bat-файл. IDE по нажатию кнопки "сделайте нам красиво" выбирает нужный тулчейн, например, для компиляции проекта. По завершении тулчейна IDE проверяет коды завершения и обеспечивает дружественный интерфейс для их интерпретации. Например, если при компиляции были ошибки, то IDE показывает их перечень и по щелчку на ошибке открывает исходник и подсвечивает ошибочную строку. Без IDE с одним лишь тулчейном это приходится делать вручную.

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

Точнее будет сказать, что toolchain != IDE, но IDE + toolchain = framework. Но опять же не по-русски, сплошной пиджин.

[Dale]

Я, пожалуй, сделаю так.

Жалко задерживать выход интересной статьи из-за того, что русскоязычные термины для данной предметной области еще не устаканились. Буду пока включать английский оригинал, а в нашей Вики представлю свое толкование термина. Когда статья будет готова, обсудим, и если найдем вариант получше, подправим. Так мне кажется конструктивнее.

[Джон]

Точнее будет сказать, что toolchain != IDE, но IDE + toolchain = framework. Но опять же не по-русски, сплошной пиджин.

Ну в принципе согласен. IDE слишком объёмно. Под IDE я просто понимал не обязательно продвинутые современные среды а ля Студия, а именно одну toolchain из них: сохранение кода после редактирования (редактор), комиляция, линковка, запуск. Но по сути это есть toolchain.

Буду пока включать английский оригинал, а в нашей Вики представлю свое толкование термина.

ИМХО самое идеальное решение.

зы По ходу мысли, как вариант:

"пакетная обработка" / "пакетный обработчик" задач.

[Dale]

ИМХО самое идеальное решение.

Идеальным будет, если получится термины сделать гиперссылками на Вики. Пока вроде принципиальных проблем не вижу, а там посмотрим.

[Джон]

Конечно получится. В этом вся соль. Я такое (термины со ссылками на вики) когда-то хотел в разделе "Фото" сделать, но до сих пор руки не дошли.

[Dale]

Перевод почти готов. Кто подскажет, каким образом его лучше выложить на обсуждение?

[Sla]

Можешь здесь, но это не есть хорошо... (она может быть проиндексирована)
А можешь подождать, пока кто-нибудь из админов не запишет тебя в "авторы" и тогда в специальном разделе. Но тогда в обсуждении будут участвовать только авторы и админы, впрочем, это те, кто здесь хоть что-то сказал.

[Dimka]

Я не согласен, что framework - это синоним toolchain. Framework - это понятие, по смыслу более близкое к библиотеке (library), нежели к интегрированной среде разработки (IDE). Если библиотека предоставляет множество полезных наработок, могущих использоваться как "кубики конструктора", ускоряющих разработку программы, то framework помимо "кубиков" содержит ещё и методику работы с ними, и готовые расширяемые и адаптируемые под конкретные нужды типовые решения и схемы решений.

[Finch]

Dale, Я тебя добавил в группу "Авторы" Должен появится доступ https://forum.shelek.ru/index.php/board,118.0.html

[Dale]

Finch, спасибо. Попробую в ближайшее время, мне уже совсем немного осталось доделать.

[RXL]

В Вики сделал раздел для терминов: Перевод технических терминов на русский язык.
На той странице надо добавлять ссылки по следующему типу:

Код:

* [[Firmware]]
* [[Framework|Иное написание ссылки, если нужно]]

Это сразу и пункт списка, и ссылка на статью. Далее, перейдя по этой ссылке попадаем на страницу с отсутствующей статьей, вводим там нужный текст и сохраняем. В каждую статью с описанием термина надо в конец добавить категорию:

Код:

[[Category:Русские термины]]

Напоминаю, что в формате Вики одиночный перевод строки рассматривается как пробел, два - как новый абзац, а все более двух - как пустые строки (<br>).
Описание формата можно прочесть здесь: язык разметки Вики.

[Dale]

Спасибо, я нашел справку. Вроде описано подробно, лишних вопросов не должно возникнуть.

В Вики сделал раздел для терминов: Перевод технических терминов на русский язык

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

[RXL]

"Глоссарий" добавил как пункт данной статьи. В саму статью в начало можно написать еще некоторый вступительно-описательный текст.

[RXL]

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

[Dale]

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

[RXL]

Ну, это другое дело...

Например (также раскидал текст по частям и подправил последнее предложение):

Код:

__TOC__

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

==Варианты трактования==
===Программно-аппаратное обеспечение микроконтроллера===
Возможные значения перевода:  «программно-аппаратное обеспечение микроконтроллера», «микроконтроллер».

Обычно имеется в виду сочетание некоего программируемого оборудования (обычно микропроцессора или микроконтроллера с соответствующим набором периферии) и программного обеспечения, предназначенное для решения определенной задачи (чаще всего управление некоторым объектом).

===Программное обеспечение микроконтроллера===
Возможные значения перевода: «программное обеспечение микроконтроллера», «прошивка», «микропрограмма».

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

==Внешние источники==
В Википедии запрос «[http://ru.wikipedia.org/wiki/Firmware Firmware]» автоматически перенаправляется на статью «[http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 Микропрограмма]», однако с такой однозначной интерпретацией трудно согласиться.

[[Category:Русские термины]]

В Вики это не заносил.

[Dale]

ОК, буду понемногу приводить в порядок. Сразу все трудно - приходится из еще сырой статьи ссылаться на еще пустую Вики... Придется мелкими итерациями.

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

[Dale]

В блоге генерального директора издательства "Диалектика-Вильямс" Виктора Штонды попались мнения читателей по обсуждаемой теме:

У меня есть только одно пожелание, наверняка субъективное и спорное, но все же озвучу: возможно, не стоит переводить общеизвестные аббревиатуры и сочетания слов, такие как Test-Driven Development, Domain Driven Design, Continuous Integration, Dependency Injection и многие другие. Когда читал перевод книги Нильсона - спотыкался об них первые полкниги. Возможно, это вопрос привычки, но, думаю, для многих программистов эти термины более знакомы в их англоязычном эквиваленте.

Многие слова и сочитания не имеют простого перевода на русский. Чтобы передать смысл понятия, например DDD нужно потрудиться. Более менее близкий перевод - "проектирование на основе модели предметной области". Но и он несёт отпечаток уже не тот. Во-первых Design это не проектирование. Это симбиооз программирования и размышления чего я делаю. А проектирование - это деятельность перед программированием, целая фаза. Поэтому в контекте DDD слово Design будет больше походить на программирование. Но и так его нельзя перевести, так как в русском языке теряется привкус проектирования. Можно сказать "конструирование" - но это костоязычно для практика.

Вариант "Предметная модель управляет конструированием" где-то близко к смыслу. Но звучит крайне невежественно.

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

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

Присоединяюсь к мнению, что термины переводить не нужно. Перевод очень (нет - ОЧЕНЬ!) мешает. Хотя бы в скобках оставляйте оригинальное название. Когда читал книгу Джимми Нильссона постоянно делал мысленное упражнение - замену русского термина на английский перед осмыслением предложения.
Перевод конечно же должен быть. Но практика такова, что в жизни все используют английские термины. И будут использовать всегда по одной простой причине - разработчики 70-95% технических текстов воспринимают на английском. Это блоги, статьи, форумы, справка средства разработки, книги, общение с коллегами и прочее. Кроме того, к моменту выхода книги даже на английском термины уже успевают устояться - они встречаются в блогах, статьях, реальных продуктах. Русский аналог становится бесполезным.
Поэтому, например, "DDD" так и останется "DDD".

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

Переводить термины в технической литературе НЕЛЬЗЯ! Последий мой негативный опыт в этой области -- попытка чтения "Шаблоны тестирования xUnit: рефакторинг кода тестов". Я не смог осилить и пятидесяти страниц (при том, что в оригинале прочитал всю книгу).

Вывод: я не куплю большую синюю книгу Эванса, если увижу в ней переведенные термины.

По-моему, заслуживает внимания.

[baldr]

Dale, по-моему все рано или поздно приходят к этому мнению
Максимум что допустимо - это транслитерация терминов и имен собственных, но переводить - получится хуже только..

[Dale]

Да, но согласно диалектике все равно сначала должна пройти стадия отрицания

[Dimka]

Лично мне не вполне понятна вот эта позиция избегания перевода. Означает ли в обычном (обывательском) английском языке "Domain Driven Design" то, что под этим понимает специалист? Конечно нет. Придумали термин, наполнили его смыслом, при этом смысл отдельных слов термина не вполне совпадает с оттенками смысла целого термина. С выражением "проектирование, основанное на модели предметной области" то же самое. Да, слово "проектирование" не вполне точно соответствует слову "design" - хоть в литературном, хоть в техническом переводе. Но что мешает договориться под выражениями "Domain Driven Design" и "проектирование, основанное на модели предметной области" понимать одно и то же?

Почему им (англоязычным) можно изобретать термины (далеко не всегда удачные) на родном языке, а нам (русскоязычным) нельзя?

Я считаю, что "проектирование, основанное на модели предметной области" - это адекватный перевод. Приведите пример англоязычного контекста, употребление в котором DDD из-за разницы в оттенках смысла потребовало в русском переводе иной формулировки?

Бывают отдельные термины, перевод которых сложен. Хотя бы "to instantiate ... [something]". Русское "породить экземпляр ... [чего-нибудь]" хотя и наиболее близко по смыслу, но всё же не совсем удачно. А от "инстанцировать" лично меня коробит.

[Dale]

Увидел цитату

Переводить термины в технической литературе НЕЛЬЗЯ! Последий мой негативный опыт в этой области -- попытка чтения "Шаблоны тестирования xUnit: рефакторинг кода тестов". Я не смог осилить и пятидесяти страниц (при том, что в оригинале прочитал всю книгу).

и вспомнилось, как приобрел книгу Дубейковского "Практика функционального моделирования с All Fusion Process Modeler 4.1". Раскрыл и обнаружил, что почти ничего из прочитанного не могу понять. Вроде и сама тема для меня не новая, и программа знакомая, а вот не идет. Смысл предложения неуловимо ускользает, не могу ухватить.

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

Еще в тему: в многочисленных книгах по алголам-паскалям-сям и иже с ними орды переводчиков десятилетиями дружно переводили statement как "оператор". И все было чудесно, пока не появился Страуструп со своим C++, в котором, помимо statement, присутствовал еще и operator. Вышел конфуз: прежние "операторы" вдруг дружно перестали быть таковыми, сея в рядах программистов раздор и смуту. (В параллельной теме возможная замена "платы" на "контроллер" могла бы привести к подобному результату).

[Dimka]

"Оператор" (operator) - это часть "выражения" (expression), которое, в свою очередь, является частью законченного утверждения (буквальный перевод statement), подлежащего выполнению машиной как единое целое, однако словом "утверждение" у нас уже переводят слово assertion ("контрольное утверждение"), хотя, быть может, более правильным было бы перевести assertion как "отношение", поскольку так или иначе оно содержит сравнения (логические отношения между значениями переменных в математическом смысле) и является предикатом, который обязан быть истинным. Но и слово "отношение" уже занято в качестве перевода relation[ship], которое в данном случае даже подходит, но совершенно лишено намёка на предикат.

Остаются слова-синонимы:
- "действие" (action), но по смыслу оно означает единичный и самостоятельный акт, не часть последовательности, поэтому неудачно;
- "команда" (command), но этим словом обычно обозначают приказ выполнить действие, поэтому см. выше;
- "операция" (operation) - подходящее слово, означающее как отдельное действие, так и множество действий по плану для достижения общей цели;
- "инструкция" (instruction) - подходящее слово, означающее план или предписание о порядке выполнения операции.

С учётом того, что (обращаясь к древнейшим смыслам слов времён ENIAC и даже "Аналитической машины" Бэббиджа) программа для вычислительной машины - это план её автоматической работы, а речь в нашем случае идёт об императивных языках (на основе машины Тьюринга, предписывающих машине порядок действий), наиболее удачным переводом для statement мне кажется именно слово "инструкция".

[Dale]

...наиболее удачным переводом для statement мне кажется именно слово "инструкция".

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

Вот еще одна коллизия вспомнилась. Какой-то "умник" придумал перевести слово character как "символ" - и покатилось. "Символьная переменная", "символьный тип"... Меня сейчас пригласили прочитать курс лекций по теории формальных языков для программистов одного из подразделений нашей фирмы. Постоянно приходится мягко, но настойчиво поправлять, что character - это вообще-то не "символ", а "литера", а "символ" - это нечто совсем другое.

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

P.S. Вдогонку вспомнилось, что в литературе того же времени по ассемблерам для разных архитектур никогда не встречалось слово "оператор", только "инструкция". Ведь могут же, когда захотят...

[Dimka]

Dale, да, но в литературе по ассемблерам слово statement будто бы не используется, вместо него используется instruction.

[Dale]

В таком случае забираю обратно свою похвалу переводчикам.

Кстати, интересно, как они будут выкручиваться, если темой статьи будет применение ассемблерных вставок в программах на C++. Забавно было бы посмотреть, как они разрулят коллизию instruction/statement/operator, постоянно сваливаясь в собственноручно вырытую яму.

[Dimka]

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

[Dale]

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

Примерно как называть литеру "символом": вроде из контекста понятно, где что имеют в виду, а все равно в целом безграмотно. Или еще иногда попадается столь же нелепое сочетание "пакет Ethernet"...

[RXL]

Или еще иногда попадается столь же нелепое сочетание "пакет Ethernet"...

А у тебя есть альтернатива термину "Ethernet"?