Локализация игр глазами менеджера

Работа в локализации заставляет кричать. Иногда от счастья, иногда от ужаса. Мой коллега, менеджер проектов Allcorrect Валерий Тимченко поделился впечатлениями от работы и рассказал о самых важных ее аспектах.

Чтобы игра стала хитом, нужны большие затраты (и огромное везение). Геймплей должен приносить удовольствие, сюжет должен цеплять, прогресс должен радовать, баги должны не появляться или хотя бы не быть критическими. Качественно сделанная игра выстрелит, а количество фанатов будет расти в геометрической прогрессии. Но есть один фактор, который может свести на нет все усилия. Это халтурная локализация. Даже шедевр может затеряться на фоне колоссального количества новых проектов, если получит несколько негативных отзывов при запуске. А они, в свою очередь, могут быть написаны исключительно из-за негативного первого впечатления, оставленного корявым переводом.

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

Например, что значит слово «карта»? Карта мира или игральная карта? А может, банковская? Или натальная?

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

Что делать разработчику, чтобы игра не провалилась? Идти к нам, конечно. Казалось бы, не ядерная физика. Берешь текст, переводишь, вставляешь в игру и будет профит. Но не все так просто.

Новый проект всегда вызывает в сознании менеджера вот такой мыслительный процесс:

Сразу скажу: есть тысяча и один CAT-tool (Computer-Assisted Translation tool, не кот) для упрощения работы над локализацией. Однако из них максимум три достойны того, чтобы быть использованными. Им нужна своя полноценная статья, а пока что разберем поток мыслей менеджера.

Основа основ. Фундамент. База.

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

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

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

Что нужно отслеживать ежедневно:

Сколько слов переведено? Сколько отредактировано? Какие оценки в ходе промежуточных проверок получили лингвисты? Дополняется ли глоссарий? Соблюдаются ли требования? Единообразны ли переводы? Задает ли команда вопросы? Ответил ли на них клиент? Внесены ли правки?

Менеджер проекта должен знать ответы на все эти вопросы. Если кто-то отстает по графику, его нужно «пингануть», то есть связаться с этим исполнителем и выяснить, все ли у него хорошо. Если не хорошо — искать замену. Если качество перевода на 6 из 10, то замена тоже не будет лишней. Пустой глоссарий неизбежно ведет к неединообразию.

«Темная башня» и «Башня Тьмы» — не одно и то же, когда речь идет о названии игровой локации. И это еще безобидный пример. Хуже, когда игрок уже прочесал всю реку вдоль и поперек, но никак не может найти иглобрюха (puffer), а заветный пуховик (puffer) все это время лежал в инвентаре.

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

Он же «предпереводческий анализ».

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

Что за файл? Как структурирован? Есть ли контекст у строчек? Какое качество текста? Есть ли фразы, составляемые из отдельных строчек? Какие частицы кода вплетены в текст? Есть ли переменные? А что в них будет? Будут ли нарушаться правила языка перевода от информации в переменных? Есть ли в тексте локальные шутки? А пасхалки? Какой стиль речи у персонажей? Как они обращаются друг к другу? Формально или неформально? Насколько неформально?

И это я не затрагиваю тонкостей типа пунктуации, употребления прописных букв, форматирования и прочего. Это продвинутый уровень для клиентов, которые лично бдят за качеством каждой строчки. Таких мало, но, как правило, их педантичный подход экономит время (деньги) всем.

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

Deals {0} points of damage and apply root.

Наносит {0} единиц урона и накладывает корни.

Наносит {0} ед. урона и обездвиживает.

Можно перевести первым вариантом. Или вторым. А в идеале можно указать на грамматическую ошибку в исходном тексте и предложить сократить «points of damage» до «DMG»: мы-то знаем, что строчка будет слишком длинной, из-за чего интерфейс будет трещать по швам. Максимально допустимая длина строки — это ресурс, которого всегда мало. Каждый раз, когда получается сократить строчку без потери смысла, где-то плачет от счастья один разработчик. Избавив его от необходимости ломать голову над сокращением и сэкономив немного денег на LQA (Localization Quality Assurance, «тестирование локализации»), можно получить плюсик в карму.

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

{1} told me I'd find you here.

{1} сказал, что я найду тебя здесь.

Покажите эту фразу переводчику любого европейского языка, и ему станет плохо. Кто будет на месте «{1}»? Сколько их там будет? Он, она, оно, они? И это не говоря уже про дополнения (me и you), которые в большинстве языков тоже должны согласовываться с подлежащим и сказуемым. Такие переменные нужно безжалостно выкорчевывать, но это не всегда очевидно клиенту.

Так что если вы в следующий раз увидите в игре фразу навроде «Волна завершен» или «Бронемашина замечен», знайте: это не саботаж со стороны переводчика, просто исходная строчка была такой: «{1} completed» или «{1} spotted». Или еще хуже — это две отдельные строчки: «Wave» и «completed», «Armored vehicle» и «spotted». Отсутствие ППА + незаданный (неотвеченный) вопрос тому виной.

Кусок на пробу. Не путать с тестовым заданием.

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

You have completed the quest. Your reward awaits you!

Ты выполнил квест! Твоя награда ждет тебя!

Безобидная строчка. Солидный перевод. Вряд ли что-то может пойти не так.

Стоп. Почему к игроку обращаются на «ты», а не на «вы»? И почему «е» вместо «ё»? И что за чрезмерность в восклицательных знаках? ПЕРЕДЕЛЫВАЙТЕ.

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

Части всего локкита, распределенные между переводчиками.

Есть великолепный способ вставить себе палки в колеса — достаточно лишь поделить файлы между переводчиками вслепую. Допустим, клиент оказал вам услугу, выгрузив все строчки в один XLSX, а не в тысячу мелких файлов. Вы просто делите файл поровну между пятью переводчиками. А через неделю замечаете, что у вас один персонаж говорит сначала как десятилетний ребенок, потом как заправский диктор, а затем и вовсе скатывается во что-то невразумительное. Исход будет печальным (если вы не локализуете «Цветы для Элджернона», конечно). Редакторам придется долго и муторно причесывать тексты. Дольше и муторнее, чем если бы за фразы одного персонажа отвечал один переводчик.

Achieve 10 victories, unlock the achievement Slayer.

Get 20 likes, unlock the achievement Famous.

Complete the secret cow level, unlock the achievement Massacre.

Представим, что эти достижения разбросаны по файлу, но контекст (краткое описание строки) позволяет и отфильтровать, например, по слову «achievement». А вы распилили файл хаотично. На выходе может получиться следующее:

Одержите 10 побед, разблокируйте достижение Убивец.

Получите 20 лайков, получите достижение *Знаменитость*.

Пройдите секретный коровий уровень, откройте достижение «Резня»

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

Я, безусловно, утрирую с этими примерами. Не всегда есть возможность фильтровать файлы по контексту (часто его просто нет). Переводчики могут между собой общаться, сводя тем самым работу редактора к минимуму. Такая частая фраза, как «unlock the achievement», легко ищется по памяти переводов (так называется база данных, куда записаны все переводы данного проекта), и хороший переводчик никогда не допустит лишнего неединообразия. Правильные кавычки наверняка будут прописаны в стайлгайде (техническом задании) проекта.

И тем не менее, всех этих надежд на чудо можно избежать, пробежавшись по файлам глазами перед распределением их частей между лингвистами.

Аналог Талмуда в сфере локализации.

Как вы вообще проверяете тексты, если не знаете язык? Смысл отдавать вам переводы, если вы, как и клиент, не шарите?

А вот и шарим. Благодаря детально прописанным требованиям.

Переводчику непонятно, как обращаются друг к другу персонажи? Составляем табличку взаимодействий. С этим на «ты», с этим на «вы», а этот принц — так вообще только на «они».

Непонятно, что использовать — повелительное наклонение или неопределенную форму глагола? Спрашиваем, фиксируем ответ.

Непонятно, какие символы использовать для кавычек, апострофов, тире и т. п.? Приводим в качестве примера по предложению с каждым символом.

Непонятен стиль речи персонажа? Просим контекст и его краткую биографию.

Yo mate, I ain't gonna be sittin' here while you're showin' off out there!

Эй, чувак, я не собираюсь тут штаны протирать, пока ты там выпендриваешься!

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

You stupid or what? How could you mess up these ingredients?

Ты тупой или где? Как можно было перепутать эти ингредиенты?

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

Ты дурачок? Ты как вообще перепутал эти ингредиенты?

По-хорошему, стайлгайд должен служить маяком как для лингвистов, так и для менеджера. Но часто в него приходится вносить изменения на основе фидбека клиента.

Самый распространенный способ — кидать файл XLSX со строчками и ошибками в них. Где-то мы допустили опечатку, где-то пропустили переменную, где-то термин не тот. Из таких вещей новое требование не выцепишь, но как минимум можно составить список наиболее частых ошибок и чек-лист проверок для переводчиков и редакторов. А-ля, «Сделайте все как обычно хорошо, но вот эти вещи проверьте еще хорошЕе».

Без них отдавать файл клиенту — моветон.

Первая вещь, которую должен освоить менеджер, — это как делать спеллчек (проверку на отсутствие грамматических ошибок) на все языки. Где может быть загвоздка в такой очевидной задаче? MS Word любит находить опечатки там, где их нет (мы называем такие мнимые ошибки «невалидными алертами»). Если мы будем присылать нашим лингвистам кучу строчек на перепроверку, когда никакая перепроверка на самом деле не требуется, то рискуем попасть в сказку про мальчика, который кричал: «Волки!» Это может «раздраконить» лингвистов.

Если довериться своей интуиции, то есть вероятность упустить валидный алерт (действительную ошибку). Понимание золотой середины приходит после сотни часов спеллчека. Минимум.

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

Вторая вещь — QA (Quality Assurance, «оценка качества»). Благо все CAT имеют встроенные инструменты для автоматической проверки. Их только нужно правильно настроить — это целое искусство. Ну, и, конечно, прогнать файл по ним. Тут в игру вступает человеческий фактор. Как со стороны лингвистов, так и со стороны менеджера. Пропустить термин или переменную в массиве из 50 тысяч слов — досадный недочет. Пропустить двадцать терминов равносильно катастрофе.

Третья вещь — проверка специальных требований. Используем макросы, сторонние программы Xbench, выделяем ячейки в XLSX либо гугл-доке… Наконец, следим, чтобы файлы синхронизировались на стороне клиента, ведь нет ничего обиднее для менеджера проекта, чем тщательно проверенный файл, который просто не дошел до адресата.

Почему это интересно?

Я затронул лишь малую часть всех нюансов, которыми нужно жонглировать в работе. Попробую выразить задачи менеджера проекта в процентно-субъективном соотношении:

15 % — общение с клиентом. Созвониться, задать вопросы, написать простыню текста, задать вопросы, получить обратную связь, задать вопросы.

30 % — работа с файлами. Проанализировать, обработать, проверить, сдать.

30 % — общение с лингвистами. Объяснить задачу, сторговаться, рассчитать затраты, обменяться мемами, проверить работу.

25 % — внутренние встречи с коллегами. Обсудить проблемы, предложить решения, внедрить новые техпроцессы.

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