|
Довелось заняться аудитом локализационных материалов. Интерфейсные строки в файлах XML, база ТМ, все как у людей, но… Начинаем читать. Есть, среди прочих, строка «Отключить». Кошка, не раздумывая, подставляет из базы «Disconnect». Подставляет решительно, во все 30 вхождений строки — 100% совпадение как-никак. И плевать ей, что первая строка красовалась на кнопке подключения к серверу, а 5 из 29 последующих — на кнопке отключения элемента в списке, которое на самом деле никакой не Disconnect, а вовсе даже Remove, а в паре мест и попросту Disable. Что в результате? Сборка с ерундой в интерфейсе, эта же чушь в документации, масса замечаний от тестеров, список исправлений на доработку, новый цикл сборки-тестирования. Естественно, не из-за одной строки — при подобном подходе на каждую тысячу строк таких найдется 50-70, если не больше. И вот вроде бы сотни людей при деле, трудятся, не покладая клавиатур и мышей, а результат на выходе — гора в муках рожает мышь. Сэкономили?
|
Да уж, сэкономили так сэкономили — в лучших традициях, как говорится 🙂
А что за кошка, Андрей? Поддерживает хранение в одной и той же ТМ нескольких переводов для одинаковых сегментов оригинала? Если да — человеческий фактор однозначно, а вот в лице заказчика или исполнителя — это вопрос…
Если же нет — хм… вообще SNAFU 🙂
P.S.
В Деже guaranteed match с минимальным window и lock guaranteed matches позволяет делать предперевод обновленного проекта без боязни испортить готовые сегменты. Проверено на живом проекте (Java-приложение для мобильных телефонов), полет нормальный.
DV, конечно, была бы удобней, но в данном случае это был SDLX (ума не приложу, чем он так нравится отделам локализации некоторых вендоров). Собственно, в базе ТМ хранился один перевод, первый. Как я понимаю, он появился там в начале проекта и был вполне корректен на своем месте, но затем при переводе новых материалов был автоматически распространен на все вхождения, включая свежие, а вот на вычитке сэкономили (ну в самом деле, к чему она на 100% совпадениях ;).
Эффективный менеджмент проектов сейчас предполагает многократное использование накопленных ресурсов при любой возможности — вроде бы здравая мысль. А вот контроля за разумностью и результатом этого подхода почему-то не предполагает. Этот результат я и имел сомнительное удовольствие наблюдать уже в обновленных материалах, которые из-за этого в содержательной части просто жутьжутьжуть.
Ко мне на препарирование этот комплект попал, когда руководство заподозрило, что в их продукте не все так замечательно, как выглядит в отчетах. Тогда-то мне пришлось, среди прочего, раскручивать и эту цепочку до изначальной русской формулировки (по сути, дефект разработки уже в том, что разные вещи в оригинале названы одинаково). Ситуацию «слегка» усложняло то, что таких проблем там не единицы, а десятки, и наслаивались они годами по мере выхода новых версий. %)
Про эффективный менеджмент очень хорошо написано в «Райской машине».
Andrew, вот это — «…по сути, дефект разработки уже в том, что разные вещи в оригинале названы одинаково…» — очень верное замечание. Я работаю сейчас совершенно в другой области (не IT) и могу сказать, что ошибки в переводе в 50-70% случаев так или иначе связаны с отвратительно написанным оригиналом.
Если при создании ТМ установить флажок «Store Context Information», то ситуация несколько улучшится.
А чтобы «гора не рождала мышь», чтобы ничего не «наслаивалось годами», надо использовать специальные программные средства и работать над технологией перевода.
Контекст помогает, да, особенно если на него обращают внимание с самого начала, а не бездумно подставляют первый же «золотой кирпичик».
«надо использовать специальные программные средства и работать над технологией перевода» — подмечено настолько же гениально, насколько и неопределенно. Вот бы еще найти ту точку «П», которая простимулирует загнанных менеджеров проекта уделять внимание переводу и при этом помнить о перспективе. Искать ее каждый раз в начальственных кабинетах кажется все же не совсем правильным.
Надо редактировать. Потом, целый готовый файл, и не в кошке.
Иначе вот такая ерунда и получается…
Не обижайтесь, но мне кажется, что только высокий уровень профессионализма позволяет возводить некритичные косяки в разряд «позорных пятен на репутацию» и возмущаться.
Я его пока не достигла, а потому наступаю на всякие распространенные грабли и задаю очевидные вопросы (бывает стыдно).
Андрей, объясните мне, как точно определить контекст по локализационным материалам (файлу ресурсов html или любого другого формата)? Я не знаю другого способа это сделать, кроме как запустить само приложение и воочию убедиться, что делает элемент, на котором располагается та или иная надпись.
Последнее мое задание — локализация приложения для мобильных устройств. Были высланы мне файлы ресурсов (HTML). Пришлось вытребовать скриншоты приложения (всего штук 20) и искать на них текст, который переводится. Потом эти ресурсы «залили» в само приложение, и я уже на смартфоне смотрела, где перевод оказался неверным (или не влез текст, например), вносила изменения в файлы ресурсов, и снова повторялся цикл. Хорошо, если разработчики и тестировщики под боком, и приложение маленькое. А как быть с удаленным переводчиком китайского, например? Предоставить ему тестовую версию приложения или заскриншотить все-все по максимуму?
Тут дело не в каком-то снобизме профи, и я прошу прощения, если такое впечатление сложилось у вас по итогам прочтения моего «стона». Ошибки — естественный феномен, они были, есть и будут, дело лишь в их количестве и предотвратимости. Одна-две случайные ошибки на 1000 слов — типичная статистика. А вот десяток ошибок, явно ставших возможными лишь из-за беcконтрольного вторичного использования накоплений в ТМ, уже сигнализирует о порочности выбранного подхода к локализации.
А его и не существует, только собрать приложение, запустить его на устройстве или в SDK/эмуляторе и там проверять логику/сочетаемость строк. Да, иногда снимки экрана выручают. Также в общем случае бывает возможно понять взаимное расположение и смысл интерфейсных элементов, если открыть начерно файлы каким-нибудь инструментом, способным воспроизвести внешний вид интерфейса и диалогов. Но в большинстве приложений сложнее «hello, world!» этого категорически недостаточно, и требуется тщательная проверка того, как работает программная логика. Именно поэтому локализация ПО — далеко не такой сверхдоходный вид бизнеса, которым некоторые его полагают, глядя со стороны. При условии надлежащего подхода к делу, конечно.