Тетради переводчика

Прочитал брошюру Microsoft Windows User Experience: Official Guidelines for User Interface Developers and Designers. Сам я разработкой ПО не занимаюсь, но полезно знать, какими принципами руководствуются создатели программ, интерфейс которых мне случается переводить. Приведу несколько рекомендаций Microsoft, которые относятся к использованию языка в пользовательском интерфейсе и могут быть интересны локализаторам.

(more…)

(в продолжение этой записи)

При переводе переменных неизвестного рода иногда можно избежать «костылей», поставив согласуемый глагол не в прошедшее время, а в настоящее. Например, попалось вам такое сообщение: [@UserName] has accepted your offer.

Вариант [@UserName] принимает ваше предложение
выглядит лучше, чем
[@UserName] принял(а) ваше предложение.

Представьте такую ситуацию: агентство дало вам проект на редактуру в формате ttx. И проверяемый перевод, к вашему удивлению, оказался настолько хорошим, что вы хотите узнать автора. (Ну, или перевод настолько плохой, что тоже хочется… узнать автора, но не будем о грустном). Агентство, конечно, своих не сдает, все коммуникации — только через менеджера. Однако есть способ узнать переводчика по полученному ttx-файлу. Способ весьма ненадежный, но у меня один раз сработал.

Откройте ttx в «Блокноте» и посмотрите в заголовок: в нем прописаны пути к ini-фильтру и исходному документу. Если этот ttx был создан переводчиком, с ненулевой вероятностью вы увидите что-нибудь вроде SourceDocumentPath="C:\Documents and Settings\Manzhosin\My Documents\source.resx". А дальше — Гугл в помощь :-)

Обратное тоже верно: не стоит давать рабочим папкам «говорящие» имена, если вы не знаете, куда в итоге попадут ваши файлы.

Нашел полезный документ: руководство по стилю для работников службы радиоэлектронной разведки. Несмотря на происхождение из АНБ, про разведку там ничего нет: это справочник трудностей словоупотребления в английском языке. Рекомендую ознакомиться, там есть интересные моменты.

После теракта в «Домодедове» многие новостные сайты изменили надпись на кнопке републикации в соцсетях (Like). Вместо дико выглядящей надписи «Нравится» на кнопке теперь указано «Рекомендую».

Замена эта правильная, и не только по этическим соображениям: «рекомендовать» — гораздо более продуктивная основа, чем «нравиться». В этом случае переводы строк вроде Unlike или Your friend %s likes this будут более согласованными.

Прекрасная заметка на сайте Павла Палажченко. Рекомендую прочитать ее целиком, а сюда вынесу самое интересное. (more…)

Нет, это не только еда на вынос [TFD]. В маркетинговом новоязе это означает основные положения, тезисы. Цитирую Раймонда Чена:

The take-away is the essential message of a presentation or the conclusion that you are expected to draw from a situation. It is something you are expected to remember when the whole thing is over, a piece of information you take away with you as you leave the room. <…> The preferred intensifier is key, and you probably see it attached to the phrase take-away more often than not. This example comes from a presentation on the results of a user study:

Results: XYZ Tough to Use

• Key take-away:
• Migration to XYZ will be difficult
• Need to show value of using the power of DEF

(And, as you may have noticed, the heading is the singular take-away even though multiple take-aways were listed.)

Если в переводимом тексте вам попался телефонный номер, копируете ли вы его в перевод? А сможет ли конечный пользователь позвонить по номеру, указанному в переводе? Зачастую автор исходного текста не имеет понятия о правилах международного набора.

Во-первых, код доступа к международной связи в разных странах разный. В России — 8,10; в США — 011. Таким образом, номер 0 11 49 228 45 67 89 в американском тексте означает «позвоните в Германию (код страны 49) в Бонн (код города 228) по номеру 456-789». Правильный способ указания международного номера описан в нормативе МСЭ Е.123: плюс и десятизначный номер без скобок, например +49 228 456 789.

Во-вторых, бесплатные «восьмисотые» номера за пределами страны вообще недоступны. В России это номера 8-800 (на них нельзя позвонить, набрав +7 800), в Штатах — 1-800. Если компания не предоставляет локального телефонного номера, в переводе к номеру 1-800 стоит добавить уточнение: «звонок только из США».

Кроме этого, в разных языках приняты разные правила форматирования местных номеров. Например, в немецком код города может отделяться косой чертой, или номер может содержать две пары скобок: (0) (228) 34 56 78.

Если вы не уверены, в какой стране писался текст и для какой предназначен, — уточните у заказчика, вашу внимательность оценят. И если не ошибаюсь, Trados 2007 не учитывает цифры в тексте при подсчете статистики: вы сможете добавить пару долларов к счету за перевод цифр.

(по материалам блога Джилл Соммер)

Некоторые переводчики вообще не делают бесплатных тестов на перевод. Кто-то делает не больше двухсот слов. Лично я не вижу проблемы в том, чтобы бесплатно перевести для потенциального клиента слов 250-300: по меньшему объему часто бывает сложно оценить уровень.

Но не все тесты одинаковы. Вот, недавно американское бюро прислало задание аж из 850 слов. Вначале я хотел перевести первые 300, но при внимательном рассмотрении в интернете нашлась полная версия этого документа на русском :-) Разумеется, я его внимательно прочитал, исправил некоторые места, в которых смог подобрать эквивалент получше, — в общем, потратил на редактуру те самые 45 минут, которые бы у меня ушли на перевод 250 слов.

Тест был успешно пройден, сейчас работаю над платным проектом для этого клиента.

Отсюда мораль: не спешите отказываться от больших тестов на перевод. Возможно, бюро хочет оценить ваши навыки поиска?

В блоге Сергея Ярославцева — отличная запись о том, как стоит и не стоит переводить повторяющиеся сегменты в документе. Прекрасная иллюстрация коварности функций Translate to fuzzy и Autopropagate. Рекомендую прочитать ее целиком у Сергея, а здесь приведу выдержку.

Вот технический документ — паспорт безопасности материала. Это таблица, в ее левом столбце встречается одно и то же свободно выражение Not found (сокращенное до n/f). Следует ли для единообразия терминологии каждый раз переводить его на русский одним и тем же выражением? Любая CAT-программа будет придерживаться того мнения, что да. А как?

Фактически это просто прочерк в соответствующей графе таблицы, и прочерк был бы лучшим переводом этого выражения. Но ведь прочерком переводить нельзя – заказчик сличит и спросит, почему не переведено… Словом «нет» или «отсутствуют» тоже перевести нельзя.