11 февраля 2013 в 17:41

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

На Хабре не раз обсуждались вопросы локализации/интернационализации приложений. Мы – компания ABBYY Language Services – давно работаем в области лингвистических услуг, сервисов и технологий, и локализацией софта занимаемся постоянно. У нас в этом вопросе накопился значительный опыт, мы решили им поделиться, сделав больший акцент на организации всего процесса. Локализация приложений — более сложная задача, чем принято считать, и подойти к ней можно разными способами: можно изначально создать простой и понятный текст, можно вложиться в крутых переводчиков, которые из любого текста вытянут смысл, можно сделать подготовку и перевод текста «как-нибудь», но посадить сообщество или тестировщиков на выверку финального результата. Необходимо только помнить, что выверка исходного текста делается на одном языке, а выверка результата — на всех языках, т. е. усилий надо затратить в N раз больше.

Вообще, локализация — это по факту открытие еще одного рынка, и понятно, что, при принятии решения о локализации, руководство рассчитывает получить дополнительную прибыль. При этом зачастую в эту самую локализацию вкладывают лишь малую часть от общего бюджета разработки (скажем, порядка 1–2 %). Т.е. расчет идет на то, что, добавив 1 %, можно получить + 50 % дохода. Насколько реалистичными могут быть такие ожидания?

Цели и объем


Первое, с чем необходимо определиться, — для чего будет производиться локализация, на какие языки, в каком объеме и с каким качеством. Обычно целью являются бизнес-задачи — вывод продукта на новые рынки, расширение аудитории. Бывают также случаи, когда продукт фактически будет продаваться на оригинальном языке, но, согласно законам государства, необходимо иметь его переведенную версию (например, различные руководства пользователя).

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

Говоря о переводе софта, можно выделить следующие основные типы контента:

  • Строки самого приложения;
  • Руководство пользователя;
  • Помощь по продукту.

При переходе к каждому последующему пункту объем информации, которую надо переводить, возрастает. Само приложение может содержать 10–100 тысяч слов, различные руководства и обучающие курсы — еще 200–500 тысяч, а полная помощь по продукту — до 1–3 миллионов слов (все, конечно, зависит от проекта).

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

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

Организация процесса


Итак, допустим, выбор сделан, локализация нужна.

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

Возможные варианты (не все, конечно) для софта:

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

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

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

Контент


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

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

В худшем случае N переводчиков, чтобы не терять время, переведут фразу так, как им будет удобно. В результате придется исправлять перевод на N языках, N раз привлекая для подтверждения корректности правки не только TRM, но и тестеров. После чего N*Х клиентов потратят время, чтобы установить обновление программы.

Терминология

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

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

Строки продукта

Существует множество способов создания контента приложения. Конкретная реализация зависит от процесса разработки, способа размещения строк и других факторов.

Частая ситуация: дизайнер, общаясь с клиентом (или продакт-маркетингом), создает первичную спецификацию продукта.

Далее программист пишет код, иногда копируя названия элементов интерфейса, иногда привнося что-то свое, включая ошибки.

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

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

Добавьте еще две проблемы:

  • Далеко не каждый программист (да и вообще, не каждый человек) даже на родном языке может четко и грамотно формулировать свои мысли (увы, но это так).
  • Команда разработчиков варится в своей специализированной области, где им все понятно, при этом используя свой собственный жаргонный язык.

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

Большую роль играет наличие проработанного стайл-гайда (пример). И, кстати, тот факт, что существует отдел технических писателей, еще не гарантирует наличие стайл-гайда.

Рассмотрим случай, когда строки все-таки проходят какой-то контроль.

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

Аспекты проверки исходного контента

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

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

Реальные примеры неунифицированного контента:
• Qty. On Hand
• OnHand Qty
• On-hand Quantity
• On Hand Qty.
• Qty on Hand
• Quantity On Hand
• On Hand Qty
• On Hand Quantity
• Qty On Hand

• Start Date cannot be greater than the End Date.
• Due Date cannot be before Start Date.
• End Date Cannot Be Before The Start Date.
• Start Date may not be greater than the End Date.
• From Date cannot be greater than To Date.
• The Star date cannot be greater than the End date.
• The star date cannot be greater than the end date.
• From Date cannont be greater than To Date.
• From Date cannot be later than To Date.
• Start date cannot be greater then End date.
• The Start date cannot be greater than the End date.
• Begin Date may not be greater than the End Date.

• Invoice not found.
• Invoice cannot be found.
• Unable to find invoice.
• Invoice wasn't found.

Приведенные примеры – это по смыслу одинаковые строки, но при этом их создают разные программисты в разных отделах. Вместо того, чтобы везде использовать что-то одно, у нас 10 вариантов, за перевод которых надо платить деньги.

Система Controlled Language

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

  • Текст воспринимается проще, облегчается работа с продуктом, что выгодно и тем клиентам, которые используют программу на ее оригинальном языке.
  • Повышается качество перевода: при переводе простого текста допускается меньше ошибок.
  • Сокращается стоимость перевода: при ограниченном наборе слов, фраз и конструкций возрастает объем частичных совпадений (а также 100%-ных совпадений и повторов).
  • Улучшается качество вспомогательного контента: как за счет «фундамента» в виде лучших софтовых строк, так и от непосредственного применения системы CL.
  • Повышается качество машинного перевода: CL позволяет убрать многозначность, которая является одной из основных проблем, влияющих на качество МТ.

Controlled Language можно разворачивать у себя внутри, можно отдавать подрядчикам, например, просто как перевод с English на Simplified English.

Резюме




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

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

Автор поста fridge.

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


Отказывать программисту никак нельзя, но и обнажёнка — это как-то слишком. Поэтому вот вам:

Автор: @ABBYYTeam
ABBYY
рейтинг 86,20
Action information

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

  • +56
    Картинка конечно отличная. Но вот вспомнил, не расскажите, куда дели грант в 450млн. рублей от Сколково? Обещали же compreno допилить. Два уже года прошло, а что-то ни слуху ни духу.
    • +27
      Ну что ж вы так? Так усердно старались внимание отвлечь и на тебе, не удалось… Не в бровь, а в глаз!
    • +17
      Тсссс!
    • +8
      [irony on]
      Конечно же, всё украли, 70% отдали Путину с Медведевым в виде откатов, остаток сами разворовали. Пора заводить трактор, сколько можно так жить?
      [irony off]
      Прекрасно помню то обсуждение на Хабре с абсурдными обвинениями в адрес ABBYY.
    • 0
      «Обещали же compreno допилить». Обещали допилить — распилили. Че еще надо?
      • 0
        Прошлый раз хабр разделился на тех кто подшучивал и тех кто защищал abbyy. Продукт всё же реальный, интересно как оно на самом деле.
      • 0
        Итак, ABBYY рассказали, что они сделали на грант. Поздравляю вас совравши-с, господин хороший.
    • +17
      Господа,

      Компрено мы демонстрируем десяткам корпоративных клиентов (включая крупнейшие компании России ;-)), ученикам наших кафедр, посетителям всяких разных выставок и конференций (типа Диалога, IT-саммита и т.д.). Ведется несколкьо пилотных проектов, причем в разных областях применения технологии — и в переводе, в поиске фактов (fact extraction), умном поиске.
      То есть, мы запустили Compreno в режиме soft launch.
      Если Вы хотите посомтреть на технологию — пишите пожалуйста запрос в личку, организуем встречу, покажем.

      Пресс-релиз, прессу, фанфары мы пока не включали, потому что эта технология рассчитана на B2B, ее «громко» запускать без демонстрации нескольких успешных внедрений и счастливых клиентов нецелесообразно. Эффект на порядок меньше будет.

      А что касается внедрений — то они уже пошли. Но цикл внедрения технологии такого масштаба долгий, дольше, чем FineReder или даже FlexiCapture поставить.

      Надеюсь, что течение ближайших месяцев будут результаты с хорошим, заметным ROI.
      • –4
        Ну а рассказать-то простым смертным никак нельзя что там да как? Вы же деньги от государства получили за просто так на это.
        • +12
          Да мы посмтоянно рассказываем, что можно (см. ниже несколкьо статей толкьо за 2012).
          Вас какой-то конкретно аспект интересует?

          1. «Детали мира»
          «Охотники за словами»
          Интервью Владимира Селегея
          www.abbyy.ru/adx/aspx/adxGetMedia.aspx?DocID=21703

          2. «Акция»
          «Она все поймет»
          Интервью Александра Рылова
          www.akzia.ru/hitech/08-10-2012/3151.html

          3. CEO
          «Президент и СЕО Группы компаний ABBYY Сергей Андреев научит компьютер говорить по-человечески»
          Интервью Сергея Андреева
          www.abbyy.ru/adx/aspx/adxGetMedia.aspx?DocID=18856

          4. Телеканал «Россия 24»
          Сюжет о технологии ABBYY Compreno
          www.youtube.com/watch?v=6_nSJFdP-vQ

          5. Hard’n’Soft
          «А теперь Compreno»
          www.abbyy.ru/Default.aspx?DN=d8896a40-e3a6-4af9-b51a-7441381ee0b1

          6. «Бизнес журнал»
          «В прямом смысле»
          Колонка шеф-редактора Дениса Викторова
          www.business-magazine.ru/profiles/editorcredo/pub344141

          7. 3DNews
          «Лингвистические технологии ABBYY: от сложного к совершенству»
          Статья Андрея Крупина
          www.3dnews.ru/software/624398/

          8. КоммерсантЪ Наука
          «Программисты считают, что научили машину понимать смысл текста»
          Статья Андрея Анненкова:
          www.kommersant.ru/doc-rss/1822898
          • –9
            Ну я же про местный бложик говорил.
            • +6
              Ну мы с местного бложика и начали рассказывать.
          • +2
            Мне понравилась 5-я ссылка.
            Так все-таки в настоящее время Сотргепо существует только как технология или есть уже готовая ее практическая реализация?
            ФайнРидером распознавали?:3
        • +5
          А, вот еще!
          у нас етсь чудесный партнер — компания Базелевс, которая создала проект Киноязык на основе Compreno.
          Попросту говоря, это автоматическая мульт-анимация текста.
          Анализом и пониманием, чего там в тексте делают герои мультиков, занимается Compreno.

          Посмотрите на первые творения:
          obosmeisya.ru/gallery/video/chromosapiens-seriya-01
          obosmeisya.ru/gallery/video/chromosapiens-seriya-02
          obosmeisya.ru/gallery/video/chromosapiens-seriya-03
          obosmeisya.ru/gallery/video/hromosapiens-seriya-04

          А свой ролик на основе этих персонажей можно создать прямо здесь:
          obosmeisya.ru/gallery/game/chromosapiens
  • +1
    Кстати по поводу «эффективной толпы». Не к месту, но вспомнилось. Я как-то задался таким вопросом: при чем тут «эффективная толпа», «великий коммандер»(commander & conquer) и прочии «надмозги». Оказалось, никакого надмозга нет и мне всё прояснил один-знакомый-поставщик-игрушек: в нашей стране, в Украине, это способ продажи альтернативно-лицензионных игрушек: пиратка с торрентов, на обложке узнаваемая картинка, а «лицензируется» это под названием типа «эффективной толпа».

    А по существу: интересно:)
    • +1
      Как хорошо что почти лицензионные игры можно приобрести за почти реальные деньги (=

      Реальные деньги
  • 0
    Многим проектам помогают такие сервисы как transifex.com.
    Есть языковые группы, координаторы этих групп итд. Оч удобно переводить на разные языки.
    • 0
      Первое стремление при локализации — как-то вытащить текст и отдать на перевод, «выстрелил и забыл». Часто это не работает. Сервис или переводческая компания — это лишь малая часть всей цепочки, а большая и важная часть — глоссарии и исходный контент, инженерные задачи, поддержка всего переводческого цикла (включая апдейты) — это остается на стороне заказчика. Плюс выбор конкретных исполнителей и сервиса — на чем он основан? Мы планируем написать вторую часть статьи, которая будет касаться уже собственно перевода и дальнейших процессов, и там затронуть эти вопросы.
      • 0
        transifex легко подключается к репозиторию, например на github и переводы синхронизируются с кодом.
        А насчет исполнителей — там можно допускать к переводу только тех кому разрешаешь(как правило это заинтересованные в переводе носители языка на который нужно переводить), на каждый язык можно назначать несколько координаторов и группу из переводчиков. А вообще у этого сервиса есть опенсорсная версия, которую любой желающий может установить для своих нужд.
        • 0
          Отделение текста и доступ к репозиторию — это очень правильно, без всякого сарказма.
          Но вылезают вопросы:
          1. А текст-то все равно кто-то проверяет? Кто-нибудь поддерживает терминологию?
          2. Какова будет процедура инициации перевода — по любому коммиту или по графику? Если переводить, пока стабилизируется код, можно напереводить лишнего. Например, если проект идет несколько месяцев-год, то заказывая 2-3 раза за релиз (а не постоянно маленькими порциями), можно снять 5-10% переводческих костов на подобных циклах. В абсолютных цифрах особенно заметно, если много языков.
          3. Разграничение прав — понятно, но вопрос-то — как выбрать тех, кто подходит для перевода? Переводческую компанию, локальных представителей, и т.д.
          Локальные люди может и заинтересованы в переводе, но у них обычно много других важных задач, плюс не у всех у них есть профильное образование. Не всегда знание 2 языков означает, что человек может переводить.
          Переводческая компания — тоже, как выбрать, кому доверять? Небольшой проект они может вообще не заметят, переведут как-нибудь.
          4. Координаторам тоже надо платить?

          Резюме: сервис, наверняка, хороший, и, если правильно применять, можно добиться хороших результатов. Просто про процессы на своей стороне тоже надо не забывать.
          • 0
            Текстом занимаются кто-то сам по своей инициативе или кого проект самостоятельно привлекает.
            Можно, допустим, замораживать версию переводов перед релизом или не синхронизировать с репозиторием переводы которые не готовы на нужное кол-во процентов.
            Это в настройках проекта на transifex… там все настройки делаются по поводу когда отправлять переводы в репозиторий.
            Координаторам не надо платить. Я, например, являюсь координатором русских переводчиков фреймворка Django.
            Я и все переводчики сами заинтересованы в переводе, и собственно занимаемся этим бесплатно. Естественно, что не все крутые переводчики, поэтому если кто-то не уверен в своих силах, то просто не лезет и все.
  • +8
    По своему (малому) опыту могу сказать, что переводы надо заказывать ТОЛЬКО у нэйтив-спикеров. Девочка после инъяза, зарабатывающая на фрилансе составлением. переводом и коррекцией маркетинговых текстов на английском за 0.5 цента за страницу, может и переведет на пике своих знаний, и вам читать нормально будет, а носители будут кривиться от не к месту вставленной идиомы или излишне высокопарного слога.
    • 0
      Инъяз хорошо, а какой у нее нативный сертификат — дело другое…
    • +2
      Ох, ваши бы слова, да софтверным компаниям в уши. Полностью согласен!
    • +8
      Согласен с Вами. Правда, неплохо ещё убедиться, что нейтив в достаточной степени знаком с исходным языком. Как-то раз мы игру локализовывали (ru → en), переводчик-американец не стал заморачиваться и задавать вопросы о непонятных местах. В итоге, например, название квеста «Производство стали» перевёл как-то в духе “The production has been stopped”. Редактор долго голову ломал, пока не понял, что американец подумал, что «заводы встали».
      • +10
        О! Сталь! Я тут встряну не по теме. В наше время МИСИС расшифровывали как Московский Институт Сплавов имени Сталина.

        А когда Сталин стал немил, переименовали в Московский Институт Стали и Сплавов. Что абсурд, сталь и так сплав. А вы над американцем смеетесь. А он — над нами…

        И зачем я это написал?
    • +1
      Зависит от типа текста. Технический текст (софтовые строки, хэлпы) — особенно если исходный текст проверили и причесали, стандартные юридические тексты — не нэйтив справится вполне. Маркетинг, «креативный» текст — да лучше нэйтив. Кроме того, в переводческих компаниях (точнее, в LSP, Language Service Provider) принята практика «переводчик-редактор-корректор». Это, пожалуй, самая распространенная практика на рынке, если брать уровень серьезных компаний, а не «бюро переводов». Дороже — да, зато качественно. Собственно переводчик может быть нэйтивом на исходном языке, редактор- нэйтив на языке перевода, но который знает исходный язык, он проверяет параллельные тексты, а корректор- нэйтив, который не знает исходный язык, и читает только перевод. Либо проще — переводчик не нэйтив, вычитка — нэйтив.
      • 0
        Ваша схема отлично работает. Я скорее писал о том, что не надо вестись на дешевизну — на такой экономии можно все потерять.
        • 0
          А, ну тогда мы об одном и том же :). 0,5 центов за слово это все-таки перебор, даже не после инъяза берут побольше, даже за редактуру, не говоря о переводе. С таким ценником в паре английский-русский — сразу в сад, как, впрочем, и >10.
          • 0
            Похоже что об одном :) цену я утрировал, даже школьники берут чуть больше :)
  • +1
    Вы меня простите за оффтоп, но под конец рабочего дня мозг настолько «сломан», что «эффективная толпа» ввергла меня и истерику минут на 15. На меня косо смотрели сотрудники, а я не мог остановится. Начальник сказал, что мне бы поспать и отдохнуть… спасибо автору, посмеялся от души над таким пустяком. Еще раз простите за оффтоп :)
  • +3
    Спасибо за отличный обзор!
    Очень интересно упоминание систем Controlled Language. Если возможно, расскажите, пожалуйста, подробнее о вашем опыте использования этих систем. Какие самые гибкие? Привязаны ли они к какому-то конкретному языку? Есть ли у каких-нибудь из них возможность коннектиться с глоссариями CAT-инструментов?
    Заранее спасибо!
    • +2
      Мы думаем написать статью по данной тематике уже после продолжения про процесс перевода :).
      Судя по нашему опыту CL легко могут снизить издержки на перевод до 5-10%. Все не пробовали, поэтому про самые гибкие сказать не можем. В целом, у всех разный набор поддерживаемых форматов/редакторов (самостоятельный или в ворде), разный набор правил, которые можно кастомизировать и т.д. Да, системы привязаны к конкретным языкам, причем у разных систем — разные. Основной язык — английский. У CL есть возможность использования глоссариев, в каких-то системах интеграция может быть, если нет — то это можно сделать через API. Не очень понятно, что именно подразумевается под интеграцией с CAT. Скорее есть CL, в ходе работы над текстом выделяются термины и добавляются в глоссарий, который либо является частью CAT, либо поставляется как отдельный модуль к ней, либо вообще является отдельной программой. Новые термины проходят процедуру перевода и согласования, а уже потом используются— либо как часть CAT, либо через интеграции, либо через импорт-экспорт.
  • 0
    Судя по примерам, ERP системы?

    Тогда надо было осветить еще и локализацию (планы счетов, печатные документы и т.д) Как у вас это организовано?
    • +1
      Судя по примерам, ERP системы?
      Они самые. Чем больше система и число разработчиков, тем больше вариаций в тексте. «Что-то не найдено», «что-то удалено», «что-то невозможно сделать» — это все можно передать кучей разных способов, не зависимо от сущности «что-то», да и самой программы…
      Тогда надо было осветить еще и локализацию (планы счетов, печатные документы и т.д)
      Мы скорее хотели в общих чертах раскрыть весь процесс, а планы счетов, печатные документы — это уже достаточно конкретные технические детали.
      Как у вас это организовано?
      Данный пост готовился от компании ABBYY Language Services, которая входит в группу ABBYY, и которая является LSP, т.е. ее сфера деятельности — лингвистические услуги и технологии. Поэтому непосредственно у «нас» «это» не организовано :), но от клиентов идут заказы на локализацию, мы анализируем, какой контент нам выдается, периодически получаем фидбэк от переводчиков, прогоняем автоматические проверки текстов. Например, при сдаче проекта проверяется consistency текста, если для разных исходных сегментов перевод одинаков — мы отлавливаем это. В каких-то случаях переводчик мог ошибиться, а в каких-то переводчик фактически сработал унификатором контента :) — и всплывают подобные примеры.
      Планы счетов и печатные документы
      Опыт тоже имеется, но он, очевидно, не охватывает все вариации. Все зависит от того, что требуется, как реализована поддержка локализации и т.д. Далее под сущностью подразумеваем план счетов или еще что-то.
      Если система будет работать только на языке перевода (например, компания не является международной), то сущность можно загнать на языке перевода непосредственно в базу данных — на этапе внедрения. Если таких клиентов несколько — можно подготовить скрипты, которые будут это делать.
      Если хочется видеть сущность на разных языках, то можно:
      Сделать специальную таблицу, где будут храниться записи сущности на исходном языке + на нужных языках перевода. При этом надо не забыть сказать об этом отделу локализации (нужно вести список локализуемых таблиц в базе), чтобы они могли вытащить исходный текст и положить перевод обратно в базу. Не забыть, как это будет поставляться клиенту — чтобы перевод попал в финальный билд. А на рантайме дергать нужное поле записи по коду языка.
      Если переводы хранятся в отдельной таблице/файлах, то можно добавить таблицу сущности в процедуру парсинга исходных кодов, чтобы вытаскивать из нее необходимый текст, добавить вытащенный текст в материалы на перевод, вернуть обратно — чтобы механизм локализации его мог подцепить и т.д. Например, в коде добавить метод/функцию, которая на рантайме при обращении к сущности будет искать нужный перевод в таблице переводов (если используется таблица в базе для хранения файлов) — по самой строке, или по какому-нибудь идентификатору.
      Печатные формы — на основе чего они создаются?
      В общем случае — хранить сами лейблы в таблице/файлах, парсить их оттуда. Перевод можно загонять в базу, или в такие же файлы, но на локальном языке, в файл со всеми переводами и т.д. — в зависимости от механизма локализации. Нужна прослойка, которая будет подставлять лейблы на конкретную форму на исходном языке (в текстовом формате, Crystal, SSRS, и т.д.), и дополнительный метод, который будет подставлять вместо исходного текста перевод.
  • +3
    Кто бы ни занимался переводами, но мое мнение осталось неизменным: переводчик (при этом действительно квалифицированный) должен видеть само приложение, в идеале — поработать с ним на переведенном языке.
    Т.к. наиболее частая проблема даже не контекст, а конфликт ключевых фраз. Скажем:

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

    «Один файлов не найдено», да.
    • +3
      Случаи типа «Один файлов не найдено» или различие родов слов в разных языках лежат в зоне ответственности менеджера по локализации, а не переводчика.
      В сложившихся условиях довольно сложно убедить переводчика поработать с программой. Ведь, как правило, их работа оплачивается по количеству слов. Поэтому мало кто будет тратить время на глубинное изучение интерфейсов программы. Это ещё удача, когда переводчики вообще читают присылаемый наглядный материал в виде скриншотов или инструкций.
      Многие такие огрехи отлавливаются при редактировании или уже на этапе лингвистического тестирования.
    • 0
      Кто бы ни занимался переводами, но мое мнение осталось неизменным: переводчик должен видеть само приложение.
      Да, контекст крайне необходим. Об этом мы напишем подробнее в продолжении статьи :).
      Скажем: Save: Сохранение, Сохранить, Спасти, Спасение, Припасы — в различных частях элементов, скажем, будь то заголовок или кнопка, может нести совершенно разное написание.
      Это частично компенсируется вдумчивой работой над исходным текстом. Save > Save File, Save > Save a child, Save > Saved Goods. Либо использование дополнительных комментариев в материалах на перевод. Например, можно для каждой строки писать внутренний идентификатор контрола, при условии, что он сам осмысленный: Save — btnSaveFile, Save — dlgTtlSaveAChild и т.д.
      «Один файлов не найдено», да.
      Знакомо — "{0} file(s) was not found.", или просто «File(s) wasn't found.».
      Решение: проверка в коде на число файлов: «File wasn't found» для одного, «Files weren't found.» для нескольких. Или «One or more files weren't found.». Или отдельный механизм, который будет выводить нужную строку для определенного числа файлов — чтобы в том же русском согласовать правильные окончания. Да сложно, но это и есть задача подготовки локализуемого софта. Если вы готовите продукт на международный рынок, эти издержки необходимо учитывать.

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

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