Как стать автором
Обновить
54
-2
Evgeniy V. Bartov @bartov-e

ИТ/ИБ переводчик

Отправить сообщение

Спасибо, гляну.

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

Спасибо за критику, учту. Однако оговорюсь, что я именно поэтому метки и поставил: уровень - "легкий", тип публикации - "Туториал". Туториалов лучше иметь побольше разных, никогда не знаешь, кому какое объяснение лучше зайдет. Мне лично зашло это.

Про то, как вычислять Q, K и V - мне тоже интересно, буду копать в этом направлении, если найду что-то интересное, закину.

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

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

Я в свое время утомился искать, и начал сам таких "выращивать". Занимаюсь наставничеством переводчиков с 2011 года, практика показала, что этот подход дает более предсказуемые результаты, чем если искать готовых спецов на рынке.


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

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

Да нет, вроде... немцы тоже грешат :).

Да, с артиклями вечная беда. Но это уже не про рунглиш, а просто про ненативный английский. Этими ошибками грешат все неносители :).

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

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

В итоге получится, что два специалиста делают одну и ту же работу, просто один останавливается на полпути, а другой идет до конца.

Редакторы на проектах, конечно, присутствуют, но они проверяют насколько доходчиво и грамотно донес смысл переводчик до читателя, но первым "под танк" лезет переводчик — читает исходник, углубляет матчасть, вникает в механизмы/технологии/фреймворки, раскладывает инфу в голове по полкам, потом переводит.

Если он просто переводит, он обречен гнать подстрочник, а с этой задачей быстрее и дешевле справляется гуглопереводчик.

Это понятно, но таковы реалии нашей работы — я уже забыл, когда видел хорошо причесанные тексты (причем, «текстового поролона», равно как и «недосказанностей» хватает и у англоязычных, и у русскоязычных авторов).
Поэтому пропустить через редактуру — это мы, перевести с канцелярского на человечий — тоже мы :).
И собственно говоря, именно это и есть самое сложное в работе переводчика — понять бизнесовый или технический смысл, оптимизировать и структурировать смысловые зерна, отсечь лишнее (дубликаты, очевидности). Именно тут переводчики делают до 80% ошибок.

Сам же перевод готового, разжеванного смысла в английские слова — это уже фигня делов, с ним и гуглопереводчик зачастую неплохо справляется.

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

Тут за меня уже ответили, я лишь дополню ответ цитатой из уважаемого мной Chicago Manual of Style:

5.220 GOOD USAGE VERSUS COMMON USAGE
...
help (to). Omit the to when possible {talking will help resolve the problem}.

...

Спасибо, поддержу — пригождается всё, и Элеонора Гальперина (Нора Галь), и Максим Ильяхов, и William Strunk и т. д.
Сложность в том, что они пишут много и обо всем - голова пухнет всё это помнить. А тут 5 шагов, которые на 80% выносят весь рунглиш. Эта памятка сильно упростила жизнь моих коллег-переводчиков :), да и мою тоже, чего греха таить :).
Конечно, каждый из этих пяти шагов еще сильно ветвится, и я в своем блоге писал об этих ответвлениях, но танцуем именно от памятки.

Не могу понять, что плохого в объявлении ценностей на берегу? Специфика работы требует постоянно что-то изучать, поэтому одна из ценностей нашей команды — мы все время чему-то учимся. Если новенький пришел просто на время ковида отсидеться, а учиться не собирается — ну и нафига он такой нам нужен? Мне кажется, принципы, принятые в команде, надо оговаривать сразу.
Разумеется. В переводах постоянно приходится много думать над тем, что именно хотел сказать автор (я сейчас про русский, в том числе — коряво изложенных оригиналов очень много). Для таких случаев подобные шпаргалки помогают.
Я как раз читаю сейчас книгу про Devops («Проект Феникс»), многое кажется сюрреалистичным. Но судя по вашей истории, в книге описываются вполне реалистичные сценарии апокалипсиса с БД, хранилищами и т.п.:)

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

Переводчик написал «сonnect them to the network», я поправил на «get them connected», но вот сейчас вижу, что было бы еще изящнее написать «to bring them online».
Ок, но скорее всего эти замечания не по адресу. Я лишь цитировал фразы из опубликованных переводов. Надеюсь, редакторы издательств ИТ-литературы меня читают (хотя, я сильно сомневаюсь:).
Кстати, да, хотя в перебираемых парах предложений (их было более 600) он мне ни разу не попался.

Этот глагол в значении «запускать проект, начинать проект» я чаще всего встречал у американских проект-менеджеров, в форме kick off.

Информация

В рейтинге
Не участвует
Откуда
Томск, Томская обл., Россия
Дата рождения
Зарегистрирован
Активность