Компания
37,05
рейтинг
12 февраля 2014 в 17:36

Разработка → «Нетворческая» сторона локализации игр. Как мы делаем это

(Новая запись от Марины Ильиных virtualtomato, старшего менеджера проектов в All Correct Localization)

Часть 1


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

image
Иллюстрация с сайта Dageron.com

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

MemoQ принадлежит к категории ТМ-программ. TM — это translation memory, память перевода. На мой взгляд, хорошо переводить без использования подобных программ можно лишь в ряде ограниченных случаев. И сейчас речь пойдет о той части работы, которую выполняет в MemoQ менеджер проектов.

Подгрузка и статистика


Все начинается с того, что появляется файл на перевод. Это может быть Excel, Word, txt, xml, po, json… Да все, что угодно. Все операции с файлом: подсчет статистики, перевод, редактирование, проверка качества — проводятся в MemoQ. После выгрузки файла из программы исходный текст в нем заменяется переводом.

Особенностью ТМ-программ является то, что они сегментируют текст (делят его на ячейки) по одному из заданных заранее правил. И если в тексте есть повторяющиеся сегменты, то программа автоматически подставит ваш перевод во все эти сегменты далее по тексту. К каждому проекту подключается TM — память переводов. В ней хранятся все переводы, которые вы ранее выполняли по данному проекту. То есть у вас никогда не возникнет случая, когда вам придется перевести тот или иной текст дважды. За это ТМ-программы все и любят.

Вот, например, это всем известное стихотворение изобилует повторами:

image

А вот как перевод одного сегмента подставляется во все остальные:

image

Статистика показывает, что в данном тексте 67% повторяющихся сегментов. Вместо 246 слов нужно фактически перевести всего 81 слово.

image

На крупных проектах (игры объемом от 20 000 слов) такое количество повторов — это большая редкость. Обычно их доля колеблется на уровне 5-18%. Например, в Rayman Legends из 21 000 слов 2057 оказались повторами. А в одном из последних моих проектов по локализации социальной игры доля повторов в тексте достигла 18,2%. Представьте себе экономию на таком проекте, если игра локализуется, скажем, на 6 языков. Так что требуйте у локализатора скидку на повторы!

Как я уже сказала, текст сегментируется по заранее заданным правилам. Выбор правил сегментации — это одно из первых важных решений, которое должен принять менеджер. В большинстве случаев текст на перевод приходит в формате Excel. И тогда мы обычно выбираем сегментацию по ячейке. То есть одна ячейка Excel-таблицы соответствует одному сегменту в MemoQ. Также довольно часто мы сегментируем текст по предложениям. Но бывают совершенно уникальные проекты, где приходится применять что-то весьма специфическое.

Однажды мы переводили проект с корейского на русский. У клиента был определенный бюджет, поэтому, чтобы помочь ему сэкономить, мы сделали сегментацию «помельче», чтобы в проекте было побольше повторяющихся сегментов. Не вдаваясь в лишние подробности, скажу, что повторов стало действительно больше, но вот только мы не учли, что строй корейского языка разительно отличается от, скажем, русского. И в результате мы сами того не ведая активировали режим Йоды. Вот такие забавные истории у нас получились (каждая строчка была отдельным сегментов в MemoQ):

Кесивион, поссорившись с мужем,
Приготовить блюдо примирения
Собирается.

Или вот:

На ночном рынке из любопытства
Играла в казино и проиграла Елена.

И мое любимое:

Морские слоны точно сошли с ума.
Раньше на них много людей
Приходило смотреть, турбизнес
Цвел. А с каких-то пор
Они решили в футболках супермена
Нападать на туристов,
Куда годится?!

Работа с переменными


В подавляющем большинстве игр разработчики используют переменные. MemoQ может облегчить работу с ними. Например, у вас есть вот такой текст на перевод:
Get {X} [cash] for {Y} [feez]?
Do you want to refill for {X} [feez]?
Loot for {0} Fee'z?

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

image

После осуществления такой нехитрой процедуры тэги и переменные не учитываются в смете на перевод (еще немного экономии!). Неоспоримым плюсом такого подхода является легкость подстановки переменных в перевод. Они вставляются нажатием одной клавиши, а не бесконечным клацаньем по Ctll+C, Ctrl+V или набором их с нуля. Так снижается риск ошибки и сокращаются трудозатраты.

«Сложные» форматы


Очень часто нам присылают тексты в формате xml с вопросом, можем ли мы переводить так. Конечно, если переводчик откроет такой файл в блокноте, то он увидит примерно следующее:

image
Переводить «так» нельзя. Этот документ еще достаточно неплохо выглядит. Бывают случаи, когда ты просто теряешься в том хаосе из кода, который видишь, открыв документ. Риск пропустить что-то или повредить код слишком велик.
Самый стандартный xml-фильтр MemoQ менее чем за минуту приведет документ вот в такой прекрасный вид:

image

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

Большие файлы


Случилось так, что над игрой должна работать команда переводчиков. То есть более одного переводчика на один язык. Как поделить текст? Кромсать сам файл возьмется разве что какой-нибудь менеджер-эскулап. MemoQ может поделить файл ровно на столько кусочков, сколько нужно (однажды я делила файл на 12 частей). При этом сам файл остается нетронутым, создаются виртуальные копии, в которых переводчик может вносить изменения только в ту часть, к которой ему предоставил доступ менеджер. Но он видит весь документ и ход работы своего коллеги, так как они работают в одном серверном проекте. Чтобы все стало еще понятнее: мы не обмениваемся с переводчиками файлами. Они получают доступ к проектам на сервере и работают только в MemoQ.

image

Вот такими нехитрыми, а иногда, конечно, и хитрыми способами мы готовим проект к локализации: подсчитываем статистику на перевод, работаем с тегами и переменными, распределяем файлы между переводчиками. Теперь вы можете не бояться, что ваши файлы безжалостно расчленят, испортят код, а вам еще и за «перевод» тегов придется платить. Ни один нормальный поставщик услуг локализации этого не допустит. Мы скоро обязательно напишем статью о том, что же видит в MemoQ переводчик и редактор, какие преимущества дает программа им, и как это влияет на качество локализации. И эта статья обещает быть большой!
Автор: @dhamin
All Correct Localization
рейтинг 37,05
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (37)

  • +3
    Про морских львов — это уже не джедай, это хокку получается.
    • +2
      Для хокку там слишком много строк, больше похоже на танка :-)
  • +4
    Хороший обзор, спасибо, отправил Марине инвайт, чтобы продолжение она смогла написать уже из своей учётной записи.
    Что касается применения ТМ-инструментов, здесь необходимо сделать оговорку, чтобы такие программы не будут творить чудеса, если исходный контент не будет оптимизирован и последователен. Нередко внедрение ТМ-инструмента на стороне разработчика сопряжено с болезненным процессом изменения всего подхода к созданию контента, тренингом разработчиков, контент-менеджеров и технических писателей.
    Если брать игры, то вот противоречивый пример из практики:
    При переходе на новый уровень пользователю отображается текст поздравления и перечисления необходимых ачивок для перехода на следующий уровень:

    Поздравляем! Вы перешли на уровень 1. Для перехода на следующий уровень получите А.

    Молодец! Теперь вы на уровне 2. Чтобы перейти на следующий уровень, получите Б.

    Ура! Вы достигли уровня 3. Для того, чтобы перейти на следующий уровень, получите В.


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

    Поздравляем! Вы достигли уровня %n! Для перехода на следующий уровень получите %s.

    Мы бы сэкономили время и деньги на локализации в каждом языке, но потеряли бы живость игровых текстов, сделали бы их более формальными.

    Но в целом, конечно, без подобных систем эффективная локализация вообще немыслима. Лично я из всех подобных решений считаю memoQ наиболее эффективным и гибким, у нас в компании она тоже основной рабочий инструмент локализации.
    • 0
      *что такие программы не будут творить чудеса. (не успел отредактировать)
    • 0
      Если говорить о приведенном вами примере, то на практике в игровых текстах очень часто встречаются стандартизированные фразы с переменными, даже в подобных случаях. Это уж как сами разработчики решат. Ну а что касается прогнозируемых затрат на локализацию, то тут все сопоставимо (и пропорционально затратам времени на исходный текст) – больше потратили времени, больше текста написали – значит и переводить его дольше придется. Ну, то есть все очевидно – как можно считать фразы/предложения повторными, если на языке оригинала сочинить 20 разных предложений с одинаковым смыслом не так уж и просто зачастую, что уж тогда о переводе говорить (тем более качественном).
  • +1
    Я бы с удовольствием почитал статью по этой теме но ориентированную как советы разработчикам. Например как организовывать все что нужно будет потом переводить. Плюс интересно почитать про использование MemoQ для своих проектов. т.е. когда в комманде 3-5 человек.
    • +2
      Я думаю, что мы можем попробовать собрать лучший опыт наших клиентов (если они, конечно, разрешат) и представить в виде советов. Для разработчиков и всех интересующихся есть прекрасная книга Game Localization Handbook. В ней довольно очевидные вещи, но она, тем не менее, невероятно полезна для получения полного представления о процессе.
  • +4
    Огромное спасибо за инвайт!

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

    Get {X} [cash] for {Y} [feez]?
    Получить 100 монета за 10 алмазы?

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

    Это нескончаемая боль. Только единицы стараются решить эту проблему на этапе разработки.
    • 0
      Обычно проблемы плюрализации в принципе не решаемы со стороны разработчика на уровне текста (если конечно в штате нет программистов-полиглотов, знающих все языки локализации и избегающих подобных моментов).

      Один из хороших выходов (для указанного вами варианта) составление списков (по заданым правилам + словарь исключений или вручную) для форм слова в единственном и множественных числах для каждого языка. Как-то так:
      Get {X}[EN, apple, apples, apples]
      Получить {X}[RU, яблоко, яблока, яблок]
      


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

      Кроме того, если команда разработчиков рассматривает перевод на другие языки как стадию «после всей остальной работы» то у нее могут быть неприятные сюрпризы, к примеру, когда красивое слово «apple» в основном меню шириной в 120 пикселей превращается в «Unternehmenssteuerfortentwicklungsgesetz».

      Только единицы стараются решить эту проблему на этапе разработки.

      Расскажите, как решают это проблему ваши заказчики?
      • +1
        Расскажите, как решают это проблему ваши заказчики?


        А вот как вы про яблоки описали, так обычно и решают. Кто-то в полной мере для всех переменных, кто-то только для комбинации «число + переменная». Это снимает огромное количество проблем.

        разработчики должны думать о i18n до того, как выпустят продукт.


        Да!
      • 0
        Кстати, например, для веба ребята из Mozilla выпустили фреймфорк l20n, который как раз облегчает работу в подобных случаях. Я бы очень хотел его испытать на каком-нибудь проекте, пока возможность не подвернулась.
        • +2
          Мы, кстати, пробуем договориться с людьми из Mozilla, чтобы они приехали к нам на Loc Kit в апреле. Если получится, можно будет поговорить с ними в Москве.
          • 0
            Было бы классно. Ну, я в любом случае собирался приехать к вам во второй раз.
    • +1
      В ОС Android грамотно разобрались с такого типа переменными:
      Plurals
      <?xml version="1.0" encoding="utf-8"?>
      <resources>
          <plurals name="numberOfSongsAvailable">
              <item quantity="one">Znaleziono jedną piosenkę.</item>
              <item quantity="few">Znaleziono %d piosenki.</item>
              <item quantity="other">Znaleziono %d piosenek.</item>
          </plurals>
      </resources>

      По ссылке можно найти подробную информацию об этом.
      • 0
        Кстати мне кажется, что если сделать похожую систему, но с полным прописыванием условий
        Например так:
        Скрытый текст
        <entry name="numberOfAppler">
        <sub  rule="n&100==11">$(n%100; concat=auto) Одиннадцать яблоко</sub>
        <sub  rule="n%10==1">$(n%10; concat=auto) Одно яблоко</sub>
        .....
        <sub rule="">$n яблок</sub>
        </entry>
        


        Получиться отличная платформа для локализации!
        • 0
          Одиннадцать яблоко

          яблок?
          • 0
            Да, извините за ошибки.
  • +1
    СЗОТ
    Вспомнился старый проект Русефекация от ag.ru russo.ag.ru/
    Иногда переводы пиратов были в разы лучше, чем лицензии.
    • +1
      Я до определенного возраста официальных локализаций в глаза не видела:) И были очень талантливые команды. Но, к сожалению, пиратские переводы, даже самые хорошие, грешат отсебятиной. И это видно, когда начинаешь сравнивать исходный вариант с переводом. В общем-то, professionals vs. fans — это нескончаемая тема для обсуждения.
  • 0
    Поразительно! У меня знакомый пытался открыть с другом компанию, которая бы занималась локализацией. Но говорит, что найти клиентов, которым нужен перевод ПО с английского на русский крайне сложно. Если не ошибаюсь, за месяц поисков они нашли двух программистов и одну компанию. Со всех суммарно заработали около 100$ и решили, что надо закрываться. Мол сложно найти клиентов и сложно им объяснить, что это им нужно, а не просто от балды доп.язык.
    • 0
      Мы сами дискредитируем российский рынок, поощряя пиратство и неофициальные локализации. Поэтому многие сомневаются, что русская локализация окупится. Нам иногда очень подолгу приходится убеждать заказчиков, что для того или иного продукта будет неплохо добавить также русский язык. И в основном на русский мы переводим free-to-play проекты. Поэтому меня нисколько не удивляет та история, которую вы рассказали.
      • 0
        А почему free-to-play? С ними какие-то другие особенности?

        Простите, тогда немного не пойму, раз вы говорите о тех же сложностях. А что же тогда пользуется популярностью, скажем так?
        • +1
          Не уверена, что я поняла вопрос. Во free-to-play проще денег с пользователей накачать, только и всего:) А если мы говорим об игре или программе на ПК за фиксированную стоимость, то я уверена, что очень большое количество пользователей в первую очередь будет искать ее на торрент-трекере. Поэтому разработчики и не спешат раскошеливаться на официальную русскую локализацию. А крупные клиенты уже давно все распределены между вендорами. Я не обладаю какой-то точной статистикой, но в моем окружении 90% людей крутят пальцем у виска, узнав, что у меня на всех ПК дома лицензионный Windows и Ofiice стоят. Я даже иногда вру, что скачала, конечно же, чтобы не объяснять в тысячный раз мое мнение на этот счет.
          • 0
            Аа… Всё. Про free-to-play понял. Я кстати сам не любитель не лицензионных вещей.

            Если вас не затруднит, скажите пожалуйста, а какая услуга в российских компаниях, занимающихся локалицией тогда пользуется популярностью? То есть условно-говоря, Запад боится, что мы тут все пользуемся пиратским софтом, а потому вряд ли им есть интерес делать локализацию. Но тогда что они заказывают? Или тут обратная ситуация, когда наши компании делают локализацию наших же проектов на другие языки?
            • 0
              Заказывают на иностранные языки. Традиционные пары FIGS, Asia, PTbra. Это касается и российских компаний, и зарубежных.
              • 0
                Простите, не знаю терминологию. Что такое FIGS, PTbra?

                Получается пара eng-rus в плане локализации не часто применима…
                • 0
                  FIGS — французский, итальянский, немецкий, испанский. PTbra — португальский вариант бразильского.
                  • 0
                    Ааа… Спасибо.
            • 0
              Заказывают обычно русский вместе с другими языками этого уровня (в плане перспективности продаж) те клиенты, которые выпускают глобальные продукты.
  • 0
    Спасибо за статью, полагал, что переводится всё чуть ли не в блокноте.

    Подготовленное к локализации iOS-приложений имеет несколько файлов Localizable.strings (для каждого языка) условно такого содержания:

    /* Надпись на кнопке алерта, при нажатии на которую осуществляется открытие определенного URL-а в Safari */
    "openUrlButtonTitle" = "Перейти на сайт";
    
    /* Надпись на кнопке алерта, при нажатии на которую происходит отмена перехода на сайт */
    "alertCancelButtonTitle" = "Отмена";

    В используемой вами TM-программе MemoQ я не увидел, чтобы выводились какие-либо комментарии к переводимым строкам. Возникает вопрос: насколько вообще актуально писать развернутые комментарии? Если ли в этом смысл или при переводи их всё-равно никто читать не будет?

    P.S. Насколько я понимаю, если необходим перевод на несколько десятков языков, то сначала всё переводится на английский, а потом уже с английского осуществляется перевод на суахили и клингонский. Как в этом случае передать специфику выражений, сохранить общую стилистику текста?
    • 0
      Единственный способ подгрузки, который сразу пришел в голову (прошу прощения, скриншот мелковат):

      image

      То есть комментарий подгружается полностью, сегментация по знаку равно, а все, что переводчику трогать не надо, мы блокируем. После этого переводчику объясняем, как в проекте выглядят комментарии. Но тут сразу есть куча недостатков: много ручной работы, комментарии не в поле комментарии, поэтому переводчик может запутаться. Хотя это лучше, чем полное отсутствие комментариев.

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

      С посткриптумом вы угадали. Наша компания переводит на все остальные языки именно с английского. Это объясняется тем, что очень сложно найти достаточное количество переводчиков, которые бы отлично понимали русский исходник. Такие команды можно набрать для языков FIGS, но у нас просто нет такой потребности, потому что заказчики либо пишут сами на английском, либо в любом случае переводят на английский. Носителей японского или китайского с отличным знанием русского очень мало. А уж когда приходится переводить на малайский или тагалог, то тут вообще можно даже не пытаться искать.

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

      • +1
        Есть способ поизящнее

        Убрать лишнее с помощью регулярных выражений: переводчику доступен для редактирования только текст, но остальную разметку он видит.
        • 0
          Да, это гораздо изящнее. А что это за фильтр?
          • 0
            Это встроенный RegEx text filter, я набросал в нём условия для импортируемого текста: до полезного текста пробел, знак равенства, пробел, кавычка; после импортируемого текста — кавычка.
            Вообще, это самая потрясная фича в memoQ, можно работать с абсолютно любой разметкой: если разработчик приходит с YAML, JSON, lua или вообще каким-то самописным форматом текстовых ресурсов, то это не становится проблемой — любой текст можно выдернуть, не трогая разметку.
            • 0
              О, я поняла. Спасибо! Я его редко использую, потому как работаю сейчас в основном с одним клиентом, а у него все в xls. Но раз этот фильтр такой потрясающий, то буду чаще к нему обращаться в случае необходимости!
            • 0
              В SDL Trados Studio тоже можно вроде бы регулярными выражениями поделить контент на переводимый и не.

              А можно напичкать любой [текстовый] файл тегами, превратив в XML, или написать конвертер для вытягивания строк в XML и последующей обратной вставки переводов.
              • 0
                Возможно, но мы, кроме того, говорим о серверной версии продукта с «плавающими» лицензиями и терминологическим модулем.

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

Самое читаемое Разработка