Я помню, как впервые участвовал в проекте по локализации программного обеспечения. Мне было поручено перевести пользовательский интерфейс какой-то промышленной компьютерной системы с помощью сложного инструмента локализации программного обеспечения. У меня не было проблем с техническими аспектами, но перевод пользовательского интерфейса был для меня в новинку, и эта задача оказалась для меня настоящим испытанием.
На самом деле, стиль текстов не был для меня чем-то необычным. Будучи в некоторой степени знакомым с ИТ, я хорошо знал «компьютерный» язык, который обычно используется в программном обеспечении (хотя под влиянием чат-ботов и голосовых интерфейсов мое мнение с тех пор кардинально изменилось). Настоящей загадкой для меня были эти странные символы: {0}, %d, %setup% и $stop$. Я понятия не имел, что они означают и нужно ли переводить слова, заключенные между этими символами, поэтому в мгновение ока я допустил множество ошибок. Символы новой строки, обозначенные как \n, стали последним ударом по моей уверенности в себе. Я никогда раньше их не видел, и хуже всего было то, что они часто сливались с другими словами. Как будто ситуация не была достаточно нелепой, текст был на немецком языке, что делало очень сложным понять, было ли \nein «nein» или «\n» + «ein». Проектный менеджер, наверное, пожалел о своем решении поручить эту задачу такому дураку, как я, после того, как его засыпали вопросами. Возможно, он даже высказался в Твиттере.
Обнаружил, что заполнители в переведенных файлах для срочного проекта волшебным образом исчезли. #PMproblems #StartPanicking
— Lau Velázquez (@geekylau) 9 октября 2013 г.
Переводчики, которые переводят заполнитель $DepartureTime$ как $HeureDépart$, просто последовательны.
— Olivier Oswald (@ooswald) 27 июля 2011 г.
Переводчики, которые переводят заполнитель $Departure Time$ как $HeureDépart$, просто следуют единому стилю.
Тот момент, когда переводчик решает изменить форму кавычек, и половина ваших переменных в игре исчезает.
— Войтех Шуберт (@falagor)12 января 2016 г.
Спустя годы воспоминания о моем первом опыте вызывают у меня улыбку. Разумеется, я всегда уделяю время переводчикам, чтобы объяснить им, как работают переменные. А лучший способ избежать ошибок и сэкономить время для себя и своей команды — использовать регулярные выражения. С их помощью переменные можно превратить в нередактируемые и легко отслеживаемые объекты. В разных программах эти объекты называются по-разному. В Smartcat мы называем их «заполнителями». А если вам интересно, что такое регулярные выражения, то они не имеют ничего общего с светской беседой. Это шаблоны, которые используются для сопоставления и манипулирования комбинациями символов. Для изучения регулярных выражений не требуются навыки программирования. Просмотрите эту простую презентацию, подготовленную Томасом Вакье, экспертом по локализации в Yamagata Europe, чтобы понять, что такое regex (сокращение от «regular expression», регулярное выражение).
Загадочные символы
В качестве быстрого примера возьмем несколько строк из песни I’m Gonna Be (500 miles) группы The Proclaimers:
Но я бы прошел 500 миль И еще 500 миль, Чтобы стать человеком, который прошел тысячу миль, Чтобы упасть у твоей двери
Допустим, мы хотим, чтобы эти слова менялись, когда слушатель перемещается в другое место. Для этого нам понадобятся переменные:
Но я бы прошел %$1s миль И я бы прошел еще %$2s Только чтобы быть тем человеком, который прошел {spelled-number} миль Чтобы упасть у твоих {location}
Какие опасности здесь таятся? Важные символы могут быть удалены и/или использованы не по назначению. Цифры в %$1s должны следовать последовательному шаблону, а «spelled-number» и «location» не должны переводиться. К сожалению, не все это знают.
«Но почему бы просто не нанять опытного переводчика, вместо того чтобы возиться со всеми этими новичками?», — может спросить кто-то. Какими бы ни были реальные причины, стоит помнить: никто не рождается профессионалом в области локализации, но любой, кто прошел через первые трудности и приобрел в процессе бесценный опыт, может им стать.
Защита от новичков, или как спасти мир
Что же мы можем сделать, чтобы предотвратить катастрофы и сэкономить время на редактировании? Опишем переменные с помощью регулярных выражений:
Для переменных с последовательными числами: %\$\ds
Для переменных, заключенных в фигурные скобки: \{.+?\}
Лично я считаю эту шпаргалку очень полезной для составления регулярных выражений, а regex101.com — отличным онлайн-инструментом, который я рекомендую для тестирования. Теперь давайте загрузим файл, содержащий переменные, в Smartcat. Вот что мы увидим:
Переменные отображаются в виде фиолетовых единиц, которые явно не подлежат переводу и могут быть безопасно перенесены из исходного текста в язык перевода с помощью сочетания клавиш. Эти элементы останутся неизменными в переведенном документе после их загрузки. Использование заполнителей не ограничивается проектами локализации. Представьте, что у вас есть большой спецификационный лист воздушного насоса, содержащий тысячи позиций. Каждой позиции присваивается код заказа, и все они выглядят одинаково, поэтому их легко перепутать.
Один промах здесь может привести к очень печальным последствиям. Могут возникнуть ошибки при отправке заказов со склада, а правильная установка тоже может оказаться проблематичной. Клиент понесет убытки или, что еще хуже, неверные данные могут вызвать технические проблемы, которые, в свою очередь, могут привести к экологической катастрофе. Заполнители не переводятся, их нужно просто безопасно перенести на язык перевода, так зачем тратить на них время? Давайте найдем все коды заказов с помощью этого элегантного регулярного выражения [A-Z]{2}\d{4}\-\d{4} и волшебным образом превратим их в нередактируемые элементы:
Какой отличный способ упростить и ускорить процесс перевода (а также его редактирование)!
На данный момент заполнители поддерживаются по умолчанию только для распространенных форматов файлов локализации. Если вы хотите использовать их в других типах документов, сообщите нам об этом.
Я обратился к своим коллегам с вопросом об их опыте использования заполнителей.
Фёдор Безруков, исполнительный директор Logrus IT (киевский офис)
«Использование заполнителей и тегов в форматах документов — обычная ситуация в нашей работе. Они очень помогают, когда клиенты присылают файлы Excel, содержащие HTML- или XML-разметку. Благодаря поддержке заполнителей и регулярных выражений в Smartcat работать с такими ресурсами стало гораздо проще и удобнее».
Марина Ильиных, менеджер по локализации в Bookmate
«Мы часто используем переменные и форматирование в пользовательских интерфейсах наших приложений. Замена тегов и переменных на заполнители позволяет нам выполнять автоматическую проверку согласованности и защищать важные данные, такие как цены, даты подписки и ссылки».
Янис Евангелу, генеральный директор lexiQA, поделился своими смешанными чувствами:
Яннис Евангелу, генеральный директор lexiQA
«Часто возникает проблема, когда переводчики переводят текст внутри заполнителей, токенов и тегов. Также часто игнорируются символы экранирования. Большинство из них не знают, что это непереводимые лексические единицы. Проектные менеджеры тоже этого не знают. Однако такая халатность может привести к критическим ошибкам. Один переводчик рассказал мне, что ему пришлось работать с текстом, содержащим HTML-форматирование, и он перевел строку <p style="border: 1px solid red;"></p> в <π στυλ="περίγραμμα: 1 πίξελ συμπαγές κόκκινο;"></π>. Он утверждал, что, возможно, разработчик, который будет использовать этот текст, не говорит по-английски. Менеджер проекта не исправила эту ошибку, потому что сочла аргументы переводчика... разумными!
Затем в разговор вступил Рольф Клишевски, эксперт по локализации игр:
«Переводчики игр часто сталкиваются с такими вещами:
И, конечно же, с этим связаны всевозможные проблемы.
Здесь проблема заключается в том, что для некоторых направлений требуется артикль. Так, это «Багамы», но «Барбадос». Или по-немецки «die Schweiz» для «Швейцария». В таких случаях мы часто отказываемся от проекта. Обычно я советую клиентам сменить текстовый движок, потому что не хочу поставлять некачественную работу. Разработчики обычно спрашивают: «Это действительно такая большая проблема?» И я отвечаю: «Нет, потому что в игру можно играть». Так как же решать такие проблемы? Сообщите об этом клиенту, объясните проблему. Если они не могут или не хотят исправлять движок, а вам нужны деньги, выполните работу, но убедитесь, что вас не укажут в титрах.
