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

ТОП 10 самых раздражающих факторов для программиста

Уверен: многие посетители некоторых коммерческих электронных библиотек подмечали, что текст невозможно скопировать естественным способом, потому что, оказывается, в него понамешана масса невидимых букв (с CSS-свойством «visibility:hidden», или «visibility:collapse», или «display:none»), так что результат копирования этого текста в буфер оказывается неудобочитаемым.

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

Сегодня же стало известно о том, что в еженощных сборках Firefox 3.7 (будущего Firefox 4) при копировании текста из него автоматически выкусываются невидимые элементы, имеющие стиль «visibility:hidden», или «visibility:collapse», или «display:none».

Многие считают, что перевод – это просто. Достаточно открыть документ и перевести текст со словарем. На самом деле, перевод представляет собой своеобразное мини-исследование: прежде, чем приступить к работе, необходимо ознакомиться с самим предметом перевода. Данный этап особенно важен, если переводчик совершенно не знаком с темой или имеет недостаточные знания для точного перевода. Кроме того, переводчику часто требуются и навыки творческой переработки текста. Например, недавно ко мне обратилось норвежское PR-агентство Say: с подобным заданием.

Если у вас блог или сайт вертится на WordPress и язык сайта не английский, — то вы точно сталкивалась с проблемой локализации.

Совсем недавно, всего пару недель назад, многие разработчики iOS начали сообщать о внесении изменений в Apple Developer Guideline. Эти изменения, cкорее относящиеся к маркетинговой стратегии, которой девелоперы могут и не интересоваться, посеяли страх и сомнения в экосистеме мобильных разработок Apple в целом. Ниже — точная цитата, затрагивающая вышеупомянутые изменения:



Перевод:
2.25 Приложения, которые отображают другие приложения (кроме своих) в целях продажи либо рекламы, которую можно спутать с рекламой в App Store, будут отклонены.

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

Идея этой небольшой статьи родилась, когда я рассказал хабраюзеру Milfgard пару жизненных историй про мой опыт как выполнения переводов, так и работы с результатами перевода. Он предложил поделиться ими с хабрасообществом, что я собственно и делаю. Надеюсь, информация хотя бы покажется интересной и, возможно, приоткроет тайны происхождения некоторых переводов.

Немного предыстории

В студенческие годы я подрабатывал внештатным переводчиком в одном из бюро переводов Москвы. Занимался я в основном переводами по тематике своего образования, то есть переводил всё, что было связано с отраслью связи и телекоммуникациями. Платили по рыночным меркам мало, но как студента меня это тогда вполне устраивало.
Вся работа бюро переводов сводилась к тому, чтобы набрать заказов как можно больше, а затем распределить это между несколькими переводчиками. По сути некий вид краудсорсинга получался. Основным объектом лингвистических издевательств становилась документация на программное обеспечение или оборудование. Самыми яркими примерами в моей памяти остались перевод документации на SDH/PDH оборудование Huawei и перевод документации на платформу Comverse. Сотрудников компаний-заказчиков мне искренне жалко, и сейчас я расскажу, почему.

Несколько недель назад в сети появился ролик-интервью с участниками отбора для проекта MARS ONE. Мы, вдохновившись переводами, решили озвучить этот ролик.
Скажу сразу, что это был первый опыт озвучания интервью, и, как оказалось, это не так уж и легко. Но, обо всём по порядку.

Мы не устаем повторять, что локализация — отличный способ выйти на новые рынки и преумножить аудиторию вашей игры. Хотя бывает, что это лишь способ потратить много времени/денег и получить перевод, над которым носители языка будут вежливо посмеиваться.



В этом посте мы законспектировали несколько идей о том, как наладить процесс локализации игр наилучшим образом. А еще написали, на чем можно сэкономить, а на чем — не стоит.

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

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

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

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

Однако есть один подход, который именно в PHP можно встретить довольно редко. Он включает использование нативного наследования и позволяет патчить код «более лучше»(с). Мы называем этот способ “Forwarding Decorator”. Нам он представляется достаточно эффективным, и, кстати, эффектным тоже, хотя последнее не так важно в продакшене.

Как автор оригинальной англоязычной статьи "Achieving Modular Architecture with Forwarding Decorators", опубликованной на SitePoint, я представляю вам авторскую версию перевода.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Controlling Your Environment Makes You Happy» автора Джоэля Спольски.

Об авторе: Джоэль Спольски, совладелец Trello, Fog Creek Software и глава Stack Overflow


Большинство разработчиков С++ терпеть не могут программирование пользовательского интерфейса. Это удивительно, так как я считаю UI-программирование до смешного простым, понятным и увлекательным.

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

Думаю, разработчики боятся UI-программирования из-за страха перед UI-дизайном. В их понимании UI-дизайн похож на графический дизайн — загадочный процесс, подвластный только творческим «total-black-look» личностям со странным пирсингом, которые поглощают латте и создают приятные глазу штуки. Программисты же видят себя логиками-аналитиками: хороши в аргументации, в творчестве — нули. Посему уверены, что дизайн интерфейсов не для них.

Представлюсь

Я ИТ-переводчик, эпизодически — преподаватель перевода.
Занимаюсь переводами я с 2006 года, читаю Habr.com регулярно, но публикуюсь здесь впервые.

На проектах, вытягивая из слов технический смысл, я иногда забредаю туда, куда обычно переводчики не заглядывают. Бывает, складываются интересные истории. Одна из них — ниже.

История

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

Я люблю такие — у них как бы есть второе дно. Оригинал выглядел так:

На эту ошибку (или, если хотите, разночтение) я обратил внимание во время проверки перевода по коммутаторам NETGEAR. Дело в том, что при переводе термина “trunk” нужно обязательно учитывать, чьей трактовки придерживается вендор — Cisco или HP, ибо между ними очень разный технический смысл.

Давайте разбираться.

---

Рассмотрим проблему на следующих примерах:

1. Cisco

2. HP

Внимательный читатель обратит внимание, что “trunk” в этих примерах имеет разное значение.

Будем «копать».

Когда я в последний раз видел Хидео Кодзиму, мы оба были голыми.

Это произошло в ротэнбуро (горячем источнике) традиционной японской гостиницы рёкан, во время отпуска компании Konami неподалёку от горы Фудзи. Тогда он ещё не начал качать железо и был намного худее. Хидео больше походил на Сайко Мэнтиса (Psycho Mantis). Сегодня он вполне бы сошёл за Снейка. Рад за него.

Хотя сейчас в это трудно поверить, но тогда, в середине 90-х, Кодзима был почти неизвестен на Западе. Впервые я встретился с ним в офисе Konami в токийском деловом районе Тораномон, где мы работали примерно с сентября 1993 года до марта 1995 года. Эти полтора года показались мне из-за сильного стресса пятью: я был единственным иностранцем в офисе и на работу приходилось добираться на поезде в ужасных условиях токийского часа пик. Позже мне предстояло заняться переводом на английский язык Metal Gear Solid — задачей, слишком масштабной для одного человека.

И вот как это было.

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

В фильме «Волк с Уолл-стрит» слово «fuck» использовали целых 569 раз — по 3,16 слов за минуту. Если перевести все эти «факи» на русский прямо, то весь фильм состоял бы из матов. Уверены, что русскоговорящие зрители это восприняли бы негативно.

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

Теория (+её производные) — ещё одно слово, на котором у меня включается творческий тупик: в голову ничего кроме theory/theoretical/theoretically не лезет. Поэтому его мы тоже с коллегами решили покрутить и так, и этак — посмотреть, как обыгрывают эту концепцию носители.
Среди примеров вы обязательно увидите мой любимый — не переводить вообще (раздел «Трансформации. Пропуски»).
В конце будет раздел «Бонус» — использование theory в необычных контекстах.

Principle

В этой книге обсуждаются как теоретические, так и практические вопросы построения компьютерных сетей.
This book discusses both the principles and practice of computer networking.

Если в переводном тексте кто-то что-то где-то начинает — то у меня сразу всплывают три дежурных варианта: begin/beginning, start/starting, first/firstly.

Судя по тому, что я вижу в присылаемых мне на проверку переводах, эта бедность речи наблюдается не только у меня. Зато у наших американских переводчиков я такого не наблюдаю — тут тебе и синонимы красивые, или вообще без всяких begin/start дело обходится.

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

Самые экзотические варианты (напр. ignite) сюда впихивать не стал, вроде и без них есть из чего выбрать (но если в будущем экзотика тоже интересует, напишите в комментах).

Поехали.

Слова-синонимы

Через последовательность действий

Я принял все предложения без споров и оправданий и начал действовать.
I accepted their advice without arguing or defending and acted on it.

Есть еще один куст слов, по которому в голову большинства переводчиков (я в их числе) в голову лезет только один дежурный набор вариантов:
участник/участие > take part/participate/participant.

Как обычно, мы посмотрели несколько переведенных с английского книг по бизнесу и ИТ (список книг внизу), развернули направление перевода (стало русско-английским), вытащили около 300 вариантов перевода, отбросили те, которые с дежурным переводом, и разложили по полочкам наиболее интересные и применимые.

Поехали.

Трансформации. Пропуск

Здесь необходимо участие обеих сторон.
It takes two to tango.

Единство мнений других участников рынка отражает цена.
That’s because the consensus view is baked into the price.

Казалось бы, база данных она и в Африке database, но читая аутентичную техническую литературу по СУБД (которую русские переводчики традиционно переводят как DBMS — database management system), я ни разу этот термин — DBMS — там не увидел (не исключаю, что плохо смотрел, но ей-богу не вру).

Получается, этот термин выдуман? И много ли такого самопала?

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

Итак, поехали.

Какие бывают?

Объектные базы данных появились в конце 1980-х — начале 1990-х годов и снова вышли из моды.
Object databases came and went again in the late 1980s and early 1990s.

В начале 2000-х появились базы данных XML, но нашли только узкое применение.
XML databases appeared in the early 2000s, but have only seen niche adoption.

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

Вариантов оказалось немыслимо много, поэтому мы выбрали только наиболее частотные, да и то просмотрели не все (там получилось свыше 500 страниц цитат, мы просмотрели около 200-300). Как обычно, разложили по полкам, смотрите.

Слова

Good, best

Я попытался собрать самые полезные из них в одном месте…
I have tried to gather together the best of these into one place…