Comments 4
Мне кажется, есть несколько причин делать технические переводы. Скажем, вы говорите/читаете по-немецки, и вам попалось что-то очень интересное. Понятное дело, вы многим окажете замечательную услугу. Или же текст написан очень живим языком, который хочется передать людям, владеющим исключительно техническим английским (до сих пор не видел близкого к совершенству перевода why's (poignant) Guide to Ruby). Возможно, имеет смысл переводить сложные по смыслу статьи, где слабое знание языка отвлекает от сути (большинство статей о настоящем таком функциональном программировании).
С другой стороны, большинство разработчиков владеют техническим английским достаточно хорошо, чтобы перевод «средней» англоязычной статьи имел под собой серьезные основания.
Как только миру только представили Swift, разработчики всех мастей стали дружно учиться на нем разговаривать. В этом плане статьи Тони, несомненно, читать приятно, полезно и нужно (особенно разработчикам, имеющим малое представление о функциональном программировании).
При всем уважении, перевод читается тяжело. Попробую аргументировать:
Есть еще «модель, подтверждающая протокол» (реализующая, видимо), «входные переменные» вместо параметров и многое другое.
Может показаться, что технический перевод — это просто. На самом деле, хороший технический перевод — это когда ты дочитал статью до конца и с удивлением обнаружил ссылку на первоисточник.
Кто-то скажет, что я придираюсь… Главное, чтобы вы не подумали, что я наезжаю. На самом деле, очень мало людей имеют желание и силы что-то переводить. Так что я всячески поддерживаю ваше начинание. Просто если уж беретесь, относитесь к делу серьезно и не забывайте о читателе.
P. S. Если моя критика не лишила вас энтузиазма, можете перевести вторую и третью части.
С другой стороны, большинство разработчиков владеют техническим английским достаточно хорошо, чтобы перевод «средней» англоязычной статьи имел под собой серьезные основания.
Как только миру только представили Swift, разработчики всех мастей стали дружно учиться на нем разговаривать. В этом плане статьи Тони, несомненно, читать приятно, полезно и нужно (особенно разработчикам, имеющим малое представление о функциональном программировании).
При всем уважении, перевод читается тяжело. Попробую аргументировать:
- Встречаются странные, местами комичные варианты перевода: response превратился в ответная реакция сети. Или же вот: многократных if-let предложений.
- Иногда искажается смысл: … случаев (case) перечисления (enum) … У перечислений бывают значения (или хотя бы варианты), а случаи бывают у операторов ветвления.
- Пропущены некоторые вещи. В оригинале есть фраза: «First, let’s look at the Maybe Monad which is similar to Swift optionals.» Собственно, без нее упоминать монады совершенно не имеет смысла (информация важна для людей с опытом функционального программирования, которые впервые знакомятся с языком Swift).
- Если беретесь переводить статью с большим количеством кода, комментарии тоже нужно переводить.
- С некоторым словами (чаще всего терминами) совсем беда. Встречаются все из перечисленных вариантов.
- Используем английский термин, русский пишем в скобках: … в своих values (значениях).
- Не переводим вообще: options парсинге, используя Applicative.
- Используем русский термин, английский пишем в скобках: функторов (Functors).
- Местами просто дословный перевод, «завернутый» в кавычки (а не обернутый).
Есть еще «модель, подтверждающая протокол» (реализующая, видимо), «входные переменные» вместо параметров и многое другое.
Может показаться, что технический перевод — это просто. На самом деле, хороший технический перевод — это когда ты дочитал статью до конца и с удивлением обнаружил ссылку на первоисточник.
Кто-то скажет, что я придираюсь… Главное, чтобы вы не подумали, что я наезжаю. На самом деле, очень мало людей имеют желание и силы что-то переводить. Так что я всячески поддерживаю ваше начинание. Просто если уж беретесь, относитесь к делу серьезно и не забывайте о читателе.
P. S. Если моя критика не лишила вас энтузиазма, можете перевести вторую и третью части.
Статья, на мой взгляд, далеко не «средненькая». Для нас, пришедших с Objective-C и начинающих осваиваться с функциональным программированием, она очень интересная и трудная, но если ты, наконец, «продираешься» через все эти монады, апликативные функторы и т.д., а также через особенности еще молодого и иногда неустойчивого Swift, то на выходе получаешь результат, который кажется «волшебным» и просто завораживает. Вот этим чувством и результатами своей «кривой» изучения функциональных возможностей Swift (ссылка на код в «Послесловии переводчика») я и хотела поделиться с аудиторией Хабрахабра. Хотелось обсуждать эту статью с русскоязычной аудиторией и для расширения этой аудитории и сделан перевод.
Swift стал языком с двумя парадигмами: императивной и функциональной, и в него полился поток с двух сторон: «функциональщики» и c Objective-C. Мы с Вами — в разных лагерях. Поэтому то, что для Вас монада Maybe кажется ключевой, для меня она таковой не является, то, что Вам кажется комичным, для меня таковым не является, ну а «завернутый»- обернутый мне кажется несущественным, если только термин «обернутый» не является устоявшимся в функциональной русскоязычной терминологией. Но это хорошо. Все можно согласовать и вам огромное спасибо за рецензию, так как всегда ценен взгляд «с той стороны».
Наличие в скобках англоязычного эквивалента лично мне очень помогает для понимания текста, так как сама читаю на английском.
Ну а вообще, друзья! Я вас призываю не просто «пройтись на лету» по этой статье, а изучить ее в коде. Вы получите огромный опыт и многое поймете в функциональном Swift.
В плане было выложить перевод оставшихся двух статей Тони, которые написаны в продолжение этой и даже еще более интересны, хотела посмотреть как пойдет. А сейчас даже и не знаю. Может Вам предоставить приоритет? А я бы в комментариях привела некоторый интересный код.
В любом случае я за более открытый подход: нужно популяризировать знания. Может быть Хабрахабр — не лучшее для этого место: я здесь новый человек?
Жаль, что оплошности моего перевода заслонили от Вас великолепный результат статьи, ибо обсуждения самой статьи и не получилось.
Swift стал языком с двумя парадигмами: императивной и функциональной, и в него полился поток с двух сторон: «функциональщики» и c Objective-C. Мы с Вами — в разных лагерях. Поэтому то, что для Вас монада Maybe кажется ключевой, для меня она таковой не является, то, что Вам кажется комичным, для меня таковым не является, ну а «завернутый»- обернутый мне кажется несущественным, если только термин «обернутый» не является устоявшимся в функциональной русскоязычной терминологией. Но это хорошо. Все можно согласовать и вам огромное спасибо за рецензию, так как всегда ценен взгляд «с той стороны».
Наличие в скобках англоязычного эквивалента лично мне очень помогает для понимания текста, так как сама читаю на английском.
Ну а вообще, друзья! Я вас призываю не просто «пройтись на лету» по этой статье, а изучить ее в коде. Вы получите огромный опыт и многое поймете в функциональном Swift.
В плане было выложить перевод оставшихся двух статей Тони, которые написаны в продолжение этой и даже еще более интересны, хотела посмотреть как пойдет. А сейчас даже и не знаю. Может Вам предоставить приоритет? А я бы в комментариях привела некоторый интересный код.
В любом случае я за более открытый подход: нужно популяризировать знания. Может быть Хабрахабр — не лучшее для этого место: я здесь новый человек?
Жаль, что оплошности моего перевода заслонили от Вас великолепный результат статьи, ибо обсуждения самой статьи и не получилось.
Самые лучшие технические статьи набирают так мало плюсиков ((
Sign up to leave a comment.
Эффективный JSON с функциональными концепциями и generics в Swift