Локализация: преодолевая языковой барьер
Одна из ключевых задач IT-компании заключается в увеличении потребительского рынка. Как только продукт становится востребованным, возникает вполне естественная потребность выйти за привычные рамки. В этот момент приходит осознание в необходимости локальной версии программного обеспечения, являющейся залогом его успешного продвижения на международной арене.
Термин «локализация», однако, все еще вызывает противоречивую реакцию. Понятие «перевод» более привычно, хотя в данном контексте оно является лишь вершиной айсберга. Ведь локализация подразумевает не только перевод пользовательского интерфейса, но и адаптацию его элементов, включая справочные материалы и вспомогательные файлы, с учетом нюансов и даже культурных особенностей целевого языка.
Какие же подводные камни ожидают специиначалиста по локализации? Условно все мероприятия по адаптации ПО укладываются в две категории: культурологическую и техническую. Хотя на практике они логично взаимосвязаны.
Начнем с культурологического компонента. Здесь важно сделать оговорку. Законодательством ряда стран (например, Франции или Испании) запрещена к распространению сугубо английская версия ПО. Она обязана идти, как минимум, в комплекте с локализованной. Тем не менее, пальму первенства в индустрии IT закономерно удерживает английский язык. Следом за ним – языки, известные в сфере локализации под аббревиатурой FIGS, — французский, итальянский, немецкий и испанский. Подход к потребительскому рынку Северной Европы находят через голландский, датский, норвежский и шведский языки (DDNS). А вот тем, кто планирует адаптировать продукт на не менее популярный японский язык, стоит учесть, что он является так называемым двухбайтовым языком, поэтому для реализации такого проекта необходимо запастись терпением и дополнительными ресурсами.
Особая статья — двунаправленные языки (Bi-Directional), к коим относятся иврит или арабский. Их отличительной чертой является то, что пишутся они справа налево. При наборе, отображении на экране или распечатке текста ПО должно распознавать это отличие. И далеко не редкость, когда заказчиком оговаривается возможность поддержки обоих типов языков — «двунаправленность».
Говоря о клиентоориентированности, но в рамках локализации, также следует учитывать и изменение формата даты, времени и дробных чисел, особенности перехода на национальную систему мер, валют, телефонных кодов, корректная сортировка алфавитных списков. Без внимания не должна остаться и нормативно-правовая сторона, где в поле зрения попадают принятые в отдельно взятой стране реквизиты юридического лица, количество знаков в индексе или идентификационном номере налогоплательщика.
При этом, достаточно ли нам найти переводчика, у которого под рукой есть словарь технических терминов? Отнюдь не всегда. Идеальный кандидат – это технический специалист, отлично разбирающийся в предметной технической области, и отменный лингвист. Помимо прочего, ему понадобиться проявить и незаурядные интеллектуальные навыки. Ведь при локализации богатство языка не должно наносить ущерб однозначной трактовке контекста. Строго говоря, адаптировать ПО со стопроцентным коэффициентом способен тот, кто имеет четкое представление о его функциональных особенностях.
Решение проблемы согласования предложений, генерируемых программой из частей – та область, которая более чем убедительно показывает отличие естественного «перевода» от «локализации». Речь идет о совместимости переведенных по отдельности фраз, которые в ходе работы программы могут сочетаться в различных вариантах. Характерным примером является фраза «Найдено 1 файлов». Решить же эту проблему без изменения кода далеко не всегда представляется невозможным.
Таким образом, мы плавно перешли к той части, где в дело включаются технические аспекты. Одним из них является заметное расхождение в объеме текстов. Так, при переводе с английского языка на русский типичный пункт меню становится длиннее в среднем на 20 – 30 %, что влечет за собой изменение размеров, расположения и выравнивания интерфейсных элементов. А с точки зрения web- и ПО-архитектуры это не приветствуется.
Неприятностей может доставить излишнее использование национальных символов в наименованиях файлов и каталогов. Даже если локализуемое ПО поддерживает полное динамическое переключение языка пользовательского интерфейса, то даже современным операционным системам не под силу сходу перевести имена файлов.
Локализация программ, работающих с текстом, подчас требует внедрения специализированных языковых модулей. Трудоемкость и сложность их разработки, например, для русского языка, как правило, чрезвычайно высоки. Впрочем, в этом случае специалисты, занимающиеся адаптацией ПО для российского рынка, избавлены от специфических проблем, характерных для двухбайтовых (китайского, японского, корейского) и двунаправленных языков (иврит, арабский, фарси). С другой стороны, русификация продукта таит в себе проблему, связанную с отсутствием единого стандарта кодировки для кириллицы.
Говоря о локализации, нельзя не упомянуть о смежном направлении – интернационализации. По сути, это спасательный круг, позволяющий значительно облегчить планируемый перевод и гео-локальную адаптацию продукта. Интернационализация, как система мероприятий, проводимых уже на этапе разработки ПО, включает использование единой кодировки, выделение всей текстовой информации в отдельный файл, возможность программного изменения форматов отображения времени, чисел, валют, сортировки списков и т.д.
Очевидно, что локализация — это комплексный процесс, состоящий из большого числа итераций и лежащий в иной плоскости по сравнению с привычным переводом отдельных интерфейсных элементов ПО. Фактор качественно выполненной локализации становится катализатором успешного продвижения продукта на региональном рынке.
С уважением, Алексей Устинов