Одна из злободневных тем, которая постоянно вызывает жаркие споры в комментариях — перевод технических текстов, в том числе терминов. Кто-то уверен, что переводить нужно, кто-то резко против, есть и те, кто считает, что оригинальные термины в русском тексте должны быть написаны по-английски.
Независимо от выбранного подхода, сложно поспорить с тем, что переводов плохого качества действительно очень много. Одна из причин заключается в том, что переводящие текст люди — не обязательно переводчики.
Я — переводчик и программист, и написала эту статью для тех, кто пытается разобраться в том, что же такое перевод и как сделать текст более качественным и точным. Здесь в упрощенном виде показан процесс перевода на примере одного из терминов, чтобы у тех, кому интересна такая деятельность, появилась как минимум пища для размышлений. Те же, кто ругает неумелые русскоязычные переводы, прочитав мою статью, смогут ругаться со знанием дела. Или, возможно, поймут, почему переводчик сделал именно такой выбор, и передумают его критиковать.
Ситуация
Итак, при переводе одной, довольно старой уже, статьи Documenting architecture decisions (автор Michael Nygard), передо мной возник вопрос: как перевести на русский язык словосочетание architecture decision?
(Для тех, кто не читал: в статье предлагается один из способов периодического описания тех или иных аспектов архитектуры программного обеспечения на протяжении разработки.)
Сторонники дословного перевода без малейшего сомнения пишут и говорят «архитектурное решение», но мне такой вариант не понравился. Я стала думать и анализировать, что в нем не так, и рассматривать другие варианты.
Первая проблема
Первая проблема: русскоязычная. Как у носителя языка, у меня при взгляде на это словосочетание возникает примерно такой образ:
То есть архитектурное решение в моей языковой картине мира в первую очередь связано именно со зданием. Опрос нерепрезентативной выборки среди носителей русского языка показал, что такая ассоциация возникает и у других. Кстати, поиск по картинкам подтверждает это. Однако проблема не в архитектурном дискурсе как в таковом, а в том, что «решение» в этом контексте, во-первых, связано с чем-то целым, а во-вторых, требует прямого дополнения: архитектурное решение системы, проекта, портала и так далее (кстати, в английском языке схожее значение имеет слово solution). В то время как в статье речь идет об атомарных периодических изменениях.
Вывод: перевод «архитектурное решение» не подходит из-за семантического несоответствия оригиналу.
Вторая проблема
Вторая проблема: англоязычная. Если мы внимательно посмотрим на словосочетание architecture decision, то увидим, что оно состоит из двух существительных. Это разновидность субстантивного атрибутивного словосочетания, в котором одно существительное является определением для другого. Но — сюрприз! — это вовсе не значит, что при переводе с английского языка на русский можно просто взять и заменить первое существительное прилагательным.
Вывод: возможно, использование прилагательного «архитектурный» для перевода architecture искажает смысл оригинала.
Чтобы правильно перевести такую конструкцию, нужно определить взаимосвязь между существительными. В некоторых классификациях насчитывается до 14 типов таких взаимосвязей. Не будем разбирать их подробно, но, учитывая знания предметной области, предположим, что на этом этапе нам подойдут варианты «decision по архитектуре» или «decision, касающийся архитектуры». В этом случае оба слова остаются существительными, а их взаимосвязь выражается с помощью падежа или причастного оборота.
Промежуточные варианты: «decision по архитектуре» или «decision, касающийся архитектуры».
Третья проблема
Третья проблема: лексическая. Как перевести слово decision? В принципе, оба варианта — «решение по архитектуре» и «решение, касающееся архитектуры» — кажутся вполне уместными, и на этом можно было бы остановиться.
Промежуточные варианты: «решение по архитектуре» или «решение, касающееся архитектуры».
Но в тексте статьи автор упоминает некий Alexandrian pattern. Речь идет о шаблоне Кристофера Александера из книги «Язык шаблонов», и в своих шаблонах К. Александер как раз использует слово solution, однако М. Найгард сознательно выбрал decision. В принципе, это не повод для отказа от первого варианта перевода — «решение», однако мне хотелось понять и точнее передать мысль автора.
Обратимся к словарю:
decision
a choice that you make about something after thinking about several possibilities.
Решение — это выбор… Попробуем использовать это слово в контексте предметной области и текста статьи.
Промежуточный вариант: выбор архитектуры.
«Выбор архитектуры» — выглядит нормально, но, как и архитектурное решение, лучше подходит к чему-то глобальному, такому как выбор монолитной или микросервисной архитектуры. Это выбор принципа или подхода к архитектуре, тогда как в статье речь идет о регулярных событиях. Подход к архитектуре в рамках реализации проекта вряд ли станет меняться несколько раз, это глобальное и редкое изменение, скорее будут добавляться или изменяться части системы. В таких случаях, наверное, можно сказать, что происходит выбор элементов (компонентов, фрагментов…) архитектуры. Слово «элемент» мне кажется более подходящим, но это, конечно, субъективное мнение.
Добавим оба этих слова к «выбору архитектуры». В результате получается «выбор элементов и принципов архитектуры». Да, это длиннее, чем «решение по архитектуре», и даже длиннее, чем «решение, касающееся архитектуры». Но слово «выбор» лучше отражает мысль автора статьи. Кроме того, это слово в полной мере описывает то, что происходит при проектировании и разработке программного обеспечения: постоянный выбор меньшего из зол — монолит или микросервисы, SQL или NoSQL, React или Vue, свой сервер или облако и так далее, и тому подобное.
Итоговый вариант: выбор элементов и принципов архитектуры.
Результат
Итак, в результате учета различных аспектов я перевела architecture decision как «выбор элементов и принципов архитектуры». Получившийся вариант хорошо звучит на русском языке, он точно передает смысл оригинала, отражает суть процесса в рамках предметной области и учитывает нюансы подбора лексики автором. В переводе нашлось место как для объективного, так и для субъективного подхода, ведь в общем и целом перевод — это тоже всегда выбор.
Комментарии (24)
nv13
17.04.2024 10:15+1Хороший пример и постановка проблемы. Я не переводчик, но пока учился в школе, довелось проходить практику в бюро перевода, работая со статьей по нейрохирургии и обсуждая ее с родственником врачом. Некоторые переведённые термины, одобренные переводчиком бюро, вызывали острую реакцию родственника) Потом столкнулся с трудностями перевода руководства по ОС TSX с термином task swapping - тогда не существовало понятия виртуальной памяти, и подобрать что то эквивалентное свопу было крайне затруднительно..Ну и последний сильно проблемный устоявшийся пример - это перевод pointer dereference))
Насколько я слышал, проблема называется проблемой переадресации перевода. Связана с тем, что в рамках двух языков смысл слов и сочетаний может быть разный. И несмотря на то, что architecture deсision по правилам дословного тех перевода следует переводить как решение архитектуры)), такой перевод нуждается в переадресации, которую Вы и проделали. Ну а некоторые вещи вообще невозможно перевести, если в целевом языке нет схожих понятий. Тогда только кофе, файл..))
anna-gorshunova Автор
17.04.2024 10:15+1Да, похоже, что процесс перевода мало кого может оставить равнодушным :)
Перевод «решение архитектуры» не подойдет, здесь родительный падеж указывает на принадлежность, а в словосочетании architecture decision связь другого типа. Пример, когда связь основана на принадлежности: management decision — решение руководства.
Вы пишете о проблеме эквивалентности перевода :) Когда значения не совпадают полностью или частично, это называется «неполная эквивалентность». Например, значения словосочетаний architecture solution или architecture decision частично совпадают со значениями словосочетания «архитектурное решение» в сфере ИТ. В строительной сфере частично совпадают значения пары «архитектурное решение» и architecture design.
nv13
17.04.2024 10:15Насчет переадресации я в "вульгарном" исполнении слышал это у Гоблина когда то давно. А потом случайно узнал, как Пруст перевёл Раскина и комментарии кого то великого типа Зализняка или Мамардашвили на этот счёт
Конечно не подойдёт, но в институте преподаватель требовала именно такой вариант как дословный и корректный.
Batalmv
17.04.2024 10:15+2Как архитектор могу ответить кратко. Правильное значение: архитектурное решение :)
Прделоженный вариант «выбор элементов и принципов архитектуры» выглядит странно и выглядит попыткой ограничить скоуп решений, которые принимает архитектор. Либо попыткой объявить все "элементом" или "принципом", но зачем?
К примеру, на проекте, целью которого была фактически замена существующего решения, одно из architecture decision фактически был покомпонентный расклад, что и как делать. Что-то переписать, что-то пересмотреть (возможно выживет какая-то часть), что-то останется и будет использовано. Можно конечно это назвать решением касательно компонентов, но скорее это процессное решение, которое влияет на то, как делать проект
Пример другого решения - как мигрировать "по живому". Это тоже архитектурное решение. И там 100500 деталей может быть
Поэтому мой совет - не стоит :)
anna-gorshunova Автор
17.04.2024 10:15Архитектурное решение [системы] — это всё же architecture solution.
Architecture decision — это решение, связанное с архитектурой, то есть выбор конкретных средств и технологий. Совокупность сделанных decisions приводит к появлению architecture solution.
То есть для создания или изменения архитектурного решения (architecture solution) вы принимаете какое-то решение (decision) или несколько. Но нельзя сказать, что вы принимаете архитектурное решение, вы принимаете просто решение. Чтобы уточнить, что это решение влияет на архитектуру, можно сказать, что вы приняли, например:
- решение по архитектуре;
- решение изменить архитектуру;
- решение изменить архитектурное решение системы и т. д. :)И, как я написала выше, можно было бы остановиться на варианте «решение по архитектуре», если пожертвовать точностью и не углубляться в контекст.
Batalmv
17.04.2024 10:15Давайте не усложнять
Solution -> просто Архитектура, либо Архитектура Системы/Решения/Продукта
Decision -> конкретное решение, оно же "выбор"
Так сложилось на практике. Хотя вот на текущем месте работы сам документ предпочитают называть Architecture Vision :)
------------------------------
Но нельзя сказать, что вы принимаете архитектурное решение, вы принимаете просто решение.
Когда я принимаю решение купить вечером пивка или нет, я принимаю просто решение :) А вот на работе я принимаю архитектурные решения, потому что "архитектор".
Architecture decision — это решение, связанное с архитектурой, то есть выбор конкретных средств и технологий.
Я уже пояснил на примере, почему решения архитектора шире :) Та же процедура миграции - эти и средства, и процедура, и еще что-то.
Есть наиболее точное и полное определение, которое по совместительству яляется конструктивным. Архитектурное решение == решение принятое архитектором в рамках выполнения рабочих обязанностей. Просто и идально :)
nv13
17.04.2024 10:15+1Если почитать исходную статью, то... прочитав, можно понять что статья про Документирование решений по архитектуре, а не про Документирование архитектурных решений - там аджайл, вальюз и прочее
Batalmv
17.04.2024 10:15+1Documentation of architecture decisions is a part of document Architecture Vision :)
Но если народ предпочитает просто вести архитектурную доку как список решений - я ж не против
anna-gorshunova Автор
17.04.2024 10:15+1Принимать архитектурное решение может, например, приемная комиссия. И здесь другое значение слова «принимать».
Решение, принятое архитектором, это архитекторское решение :) не архитектурное.
Batalmv
17.04.2024 10:15ОК, решение принятое персоной либо группой лиц в рамках выполнения обязанностей роли архитектора :)
dph
17.04.2024 10:15Э, какая приемная комиссия в обсуждении архитектуры? И нет, ADR никак не связан с принятием решения, только с документированием процесса принятия решения.
Это же просто формат документа. Если уж буквально переводить, то "Запись про принятые решения касающиеся архитектуры"anna-gorshunova Автор
17.04.2024 10:15В этой ветке мы в основном разбираемся с прилагательными: архитектура — архитектурный, архитектор — архитекторский. И со словосочетанием «принять решение».
Но раз уж зашла речь, как и почему в переводе ADR появилось слово «принятые»? Если оставаться в контексте статьи М. Найгарда, там, кроме accepted, есть proposed и deprecated, например. А если есть accepted и proposed, то разве не может быть declined или rejected?
dph
17.04.2024 10:15Не совсем так. В процессе обсуждения (proposed) ADR может редактироваться. Но потом он accepted, пока не станет deprecated. Если бы это было предложение, то называлось бы RFC или Proposal
hoack
17.04.2024 10:15+1С моей точки зрения, предлагаемый перевод искажает смысл, имеющийся в исходном тексте. Статья, о которой идет речь, обсуждает документацию именно что решений - то есть да, выбора, но выбора в широком смысле, не только компонентов и принципов, но и действий, стратегии, методологии и т.п. Слово "решение" прекрасно передает именно это значение; зачем его заменять - решительно непонятно. Ваш вариант создает впечатление, что речь идет о процессе в начале разработки проекта, когда делается выбор. В статье же говорится о более универсальном процессе, который - как это говорится в статье - может происходить на протяжении всей жизни проекта.
anna-gorshunova Автор
17.04.2024 10:15На месте автора я бы вообще назвала эти события «изменениями архитектуры» или «изменениями в архитектуре». Но такой вариант не очень подходит для описания процессов в начале разработки проекта.
С формальной точки зрения «выбор» не является заменой, это тоже вариант перевода слова decision, просто менее частотный, чем «решение». Я выбрала этот вариант, чтобы точнее передать мысль автора. В статье есть и decision, и solution — и мне показалось важным подчеркнуть это различие.
Вопрос личного восприятия, конечно, тоже важен, но мне не кажется, что «выбор» ассоциируется только с началом разработки. Думаю, вполне можно представить, что вся история проекта связана с цепочкой выбора альтернатив при возникновении различных ситуаций.
kozlov_de
17.04.2024 10:15+1Нет никакого architecture decision
Есть ADR architecture decision records
И сразу акцент с архитектуры как законченного документа уходит на выбор, записи.
Если хотите перевод, то это
Документально зафиксированный выбор варианта архитектуры
dph
17.04.2024 10:15Нет там "вариантов архитектуры", так как ADR не про "выбор варианта", а про решение одного конкретного tradeoff или про обсуждение одного конкретного изменения.
Поэтому предложенный в статье перевод - ужасен, так как полностью теряет реальный смысл фразы.
Можно перевести как "решения по поводу архитектуры" или даже "Результат обсуждения архитектуры". Или вообще не переводить, так как зачем?anna-gorshunova Автор
17.04.2024 10:15Ваш перевод «решение по поводу архитектуры» полностью совпадает по смыслу с моим промежуточным вариантом «решение по архитектуре» и «решение, касающееся архитектуры». Да, на этом можно было остановиться, но мне важно было показать влияние контекста на процесс перевода.
Вы не могли бы пояснить, что подразумеваете под решением одного конкретного tradeoff? Хочу понять, в чем здесь противоречие с «выбором варианта (элементов, принципов) архитектуры».
И еще интересно, как получился перевод «результат обсуждения архитектуры»?
dph
17.04.2024 10:15Неа, "решение по архитектуре" - это "решение про всю архитектуру", а ADR - про небольшие части архитектуры системы, а не про всю. "Решение, касающееся архитектуры" - да, гораздо лучше.
Никакого "выбора вариантов архитектуры" в ADR просто нет, документ не про "какие архитектуры можно выбрать", а про "как решить конкретную задачу-проблему, как-то касающуюся архитектуры".
А "результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие и ничего хорошего из этого не получится.anna-gorshunova Автор
17.04.2024 10:15"решение по архитектуре" - это "решение про всю архитектуру"
Попробуете обосновать? Или останется мнением на уровне личного восприятия?
ADR - про небольшие части архитектуры системы, а не про всю
Насколько небольшие? А если это ADR, в котором выбирается фреймворк? А если инструмент для форматирования кода?
"выбора вариантов архитектуры"
Случайно или нет, но вы снова изменили эту фразу, при этом исказился смысл.
«Выбор варианта архитектуры» можно трактовать так, что в результате получится вот такая разновидность устройства системы; система видоизменится определенным образом. Да, это будет сделано в рамках решения задачи или проблемы. Всё еще не понимаю, в чем здесь противоречие.
"результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие
В целом согласна, но о какой предметной области идет речь: архитектура ПО, переводоведение, русский язык?
dph
17.04.2024 10:15Не, не буду обосновывать. Но именно так это читается носителем русского языка.
Выбор фреймворка или инструмент форматирования кода - это как раз очень небольшие части архитектуры. Впрочем, инструмент форматирования кода к архитектуре вообще отношения не имеет, заводить на это ADR достаточно странно
Ну, если не понимаете - то и ладно, вы же не архитектор, вам это не обязательно. Главное - не используйте свой перевод, так как он не соответствует понятию ADR
Архитектура ПО, разумеется. Хотя про переводоведение у меня тоже есть сомнения.
anna-gorshunova Автор
17.04.2024 10:15Да, хороший вариант, спасибо. Мне кажется, допустимо рассматривать «вариант архитектуры» как видоизменение устройства системы, включая ее окружение.
А почему вы перевели record как «документально зафиксированный»? Не проще ли перевести как «запись», особенно с учетом существующей практики объединять множество ADR в журнал (log)?
ParaMara
Есть ещё одно требование именно к техническому переводу - перевод обратно на английский, в том числе сделанный на среднем уровне владения обоими языками, должен давать удобный гуглу результат. Архитектурные решения в этом смысле идеальны, но да, не без обременения. Я бы дальше «решений по архитектуре» не отходил.
Выборка среди носителей языка - грубая ошибка, допустима и даже необходима выборка среди специалистов влияющих на выбор архитектуры проектов. Заменить её можно посмотрев не переводились ли раньше architecture decisions в солидных источниках.
К слову - кнопка Start в углу рабочего стола Windows вызывает две ассоциации - начало как действие и место где собрались все к этому действию готовые. Поэтому перевод Старт лучше чем Пуск, но уже ничего не изменить.
anna-gorshunova Автор
При таком требовании придется отказаться от описательного перевода и ряда переводческих трансформаций, а это далеко не всегда возможно в принципе.
Выборка (нерепрезентативная!) среди носителей языка — это всего лишь повод для размышлений. Мне хотелось получить свободные ассоциации, вне контекста статьи. Кстати, архитекторы ПО в этой выборке тоже были. Впрочем, опираться на мнение одних только профильных специалистов я бы тоже не стала. По крайней мере, при написании текстов для широкой аудитории.
Про солидные источники — резонно. Microsoft, например, перевел ADR как «решение об / по архитектуре». Но я не знаю, обращался ли там кто-нибудь к первоисточнику и пытался ли выяснить, почему не solution. То есть при других вводных вариант «решение по архитектуре» действительно может быть окончательным. Я же описала перевод термина именно в контексте конкретной статьи, и на этом примере очень хорошо видна роль этого самого контекста.
Про кнопку интересно было бы получить комментарии переводчиков. Я нашла, что в одной ОС (не Windows) эта кнопка называлась Launch.