Бюро переводов / Статьи / Шесть вещей, которые нужно знать о локализации программного обеспечения
Шесть вещей, которые нужно знать о локализации программного обеспечения
Эта статья представляет собой компиляцию шести не связанных с технологией фактов. Несколько недель назад мы выпустили на рынок программное обеспечение с поддержкой 22 различных языков. Поскольку заказчик — немецкая команда, в качестве базового языка использовался немецкий язык. Перед заказчиком стояла задача перевести все сообщения программы с немецкого языка на 21 язык, а также осуществить локализацию других материалов (иллюстраций, документов, предназначенных для загрузки и так далее).
1. Используйте инструментарий
В первую очередь нужен инструментарий, позволяющий обеспечить доступ к исходным файлам сообщений и файлам перевода как разработчикам, так и переводчикам. Первоначально мы использовали для этих целей общую папку на облачном хранилище. Регулярно мы загружали в эту папку новые версии файлов сообщений на немецком языке. Переводчики использовали эти файлы для внесения изменений в файлы на других языках.
Очевидная проблема заключалась в том, что при использовании такого подхода возникала необходимость в большом объеме лишней работы для заказчика. Каждый раз, когда им нужно было удалить, добавить или изменить ключ сообщения, необходимо было вручную вносить изменения в 22 файла свойств. При изменении сообщения на немецком языке, они должны были сообщить об этом бюро переводов, чтобы мы могли вручную внести изменения в файлы на других языках. Очевидно, такой подход был далек от идеала.
К счастью, сейчас существуют удобные инструменты, способные помочь в процессе перевода. Мы стали использовать бесплатную программу Pootle, благодаря чему объем ручной работы значительно сократился. Впрочем, существует множество альтернативных инструментов. Также следует иметь в виду, что вовсе не обязательно использовать программу стороннего разработчика. Если вы предпочитаете сохранять локализованные сообщения в базе данных, вы можете самостоятельно создать простой CRUD-интерфейс с возможностью поиска, который может быть использован нашими переводчиками для внесения изменений в сообщения.
2. Обучайте переводчиков
Убедитесь, что переводчики полностью понимают синтаксис сообщений. Разработчику может быть предельно ясно, как работают метки-заполнители, экранирование и форматы дат. С точки зрения переводчика (который может вообще не иметь никакого опыта в разработке программного обеспечения) все вовсе не так очевидно. Если из-за неверного задания формата даты для некоторых языков генерируется исключение, например, когда формат даты DD.mm.YYYY преобразуется в формат jour/mois/an (день/месяц/год для французского языка), вы понимаете, что вам нужно поработать над этим моментом.
Объясните переводчикам, с которыми вы сотрудничаете, как работают метки-заполнители и какие символы подлежат экранированию. Приведите примеры стандартных шаблонов даты и времени и их использования в переводе. Используйте в файлах сообщений комментарии, поясняющие правила применения тех или иных опций форматирования и использования меток-заполнителей.
3. Предоставьте переводчикам контекст
Просто перевести сообщение с одного языка на другой во многих случаях недостаточно. Чтобы перевод был адекватным, переводчики должны понимать, в каком контексте отображается то или иное сообщение. Для этого необходимо предоставить им доступ к тестовой версии программного обеспечения, где они смогут увидеть, как их перевод выглядит в реальной программе.
Периодически мы посылали заказчику электронные письма, содержащие, например, такие вопросы:
В приложении сообщение X в позиции Y. Каков ключ сообщения для X?
В зависимости от сообщения Х простой поиск Х в файлах сообщений не всегда помогает (если учесть наличие меток-заполнителей, дополнительной разметки, а также слишком большого количества сообщений, содержащих Х). Мы с заказчиком решили этот вопрос, расширив возможности отображения сообщений в пользовательском интерфейсе. После этого появилась возможность отображать ключи сообщений в тестовом варианте программного продукта, добавляя дополнительный параметр URL к существующим URL приложения. Во всех случаях добавления этого параметра URL мы добавляли простой тег ‹span› с атрибутом title. То есть вместо параметра [message] мы использовали ‹span title=“[key]”›[message]‹/span›. Это дало возможность при наведении курсора на отображаемое сообщение видеть окно подсказки с ключом сообщения. Такой подход работал не в 100% случаев, поскольку в ряде ситуаций дополнительный параметр ‹span› приводил к нарушению разметки. Однако в 95% он давал нужный результат, и мы стали задавать значительно меньше вопросов заказчику.
Мы задавали также вопросы противоположного плана:
В исходном файле я вижу сообщение Х с ключом Y. Где оно должно отображаться в приложении?
Я думаю, лучшее решение этой проблемы — присвоение логических имен ключам сообщений. Мы использовали следующие простые условные обозначения для структурирования ключей сообщений:
1 [module].[section].[detail].[optional subdetail]
Вот несколько примеров:
1 news.create.title=Title
2 news.create.title.emptyError=Please add a title
3 news.create.title.maxLengthExceededError=The title cannot be longer than X characters
Это примеры сообщений, отображающихся в поле ввода заголовка в новостном модуле. Организационные уровни разбиты точками. Описание ошибок, например, maxLengthExceeded, не является описанием организации, поэтому для него используется горбатый регистр (CamelCase) вместо news.create.title.max.length.exceeded.
Однако это лишь один из вариантов, который оправдал себя в нашем конкретном случае. Вы можете использовать собственные варианты обозначений.
4. Не забывайте, что длина слов может варьироваться
В разных языках среднее количество символов в слове может значительно отличаться. Мы не приводим здесь реальной статистики по средней длине слов, можем привести несколько цифр из файлов конкретного проекта:
Среднее число символов в слове:
язык — число символов — коэффициент
английский — 5,3 — 1
португальский — 5,5 — 1,04
французский — 5,7 — 1,07
немецкий — 6,4 — 1,21
Это средние длины слов, полученные на основе нескольких файлов, каждый из которых содержит около 1500 сообщений. Конечно, это не абсолютно точные цифры — имеет значение, в частности, и тематика. Чтобы выделить отдельные слова в сообщениях, мы разбивали здесь сообщения пробелами. Слова и сообщения могут содержать дополнительную разметку, знаки препинания или метки-заполнители. Однако поскольку разметка и метки-заполнители в основном одинаковы для всех языков, приведенная выше информация может оказаться полезной. В нашем приложении средняя длина немецкого или русского слова примерно на 20% превышает среднюю длину английского слова.
Убедитесь, что пользовательский интерфейс вашего приложения поддерживает тексты разного размера. Это особенно важно, если речь идет о кнопках и элементах навигации, которые приходится расширять, если длина относящейся к ним надписи увеличивается. Также следует помнить, что там, где в одном языке используются общепринятые сокращения, в другом языке может использоваться целое слово (или даже несколько слов). Например, на страницах на английском языке часто используются такие навигационные элементы, как FAQ (часто задаваемые вопросы) и Q&A (вопросы и ответы). Хотя сообщение «Questions and Answers» может быть переведено на другие языки, общепринятой аббревиатуры для него в других языках может не оказаться. Так, в русском языке акроним ЧаВО имеет просторечные коннотации.
5. Протестируйте программное обеспечение после локализации
Тщательно протестируйте программное обеспечение после того, как локализация будет завершена. Проверьте правильность перевода, отображение нелатинских символов и функциональность программы для всех языков. Чтобы подчеркнуть важность тестирования, я хочу привести несколько примеров конкретных проблем, с которыми нам приходилось сталкиваться:
● Пользователи программы на одном из языков не могли получить электронные письма определенного типа. Оказалось, что эти письма содержали дату, отформатированную с использованием шаблона, зависящего от языковых настроек. Поскольку шаблон содержал недопустимый символ, модуль форматирования даты не срабатывал, и письмо не отправлялось адресату.
● В некоторых ситуациях метки-заполнители не заменялись на актуальное содержание. Проблема была связана с сообщениями, которые содержали неэкранированные одинарные кавычки. В Java MessageFormat метки-заполнители не заменяются, если они расположены между неэкранированными одинарными кавычками. Мы заметили эту проблему только в версии приложения, переведенной на французский язык, поскольку в сообщениях на французском языке содержится намного больше одинарных кавычек, чем в других языках, на которые выполнялся перевод.
● Элементы пользовательского интерфейса не работали из-за того, что переведенные сообщения были слишком длинными и не помещались в предназначенное для них место.
● Выяснилось, что внешняя платежная система, с которой работал заказчик, не поддерживает полный набор символов UTF-8. Поэтому на счетах-фактурах не печатались символы кириллицы.
6. Локализация может занять много времени
Процесс локализации может занять достаточно много времени, особенно если в нем принимают участие множество людей из разных стран. Следовательно, нужно тщательно его спланировать. Помните, что каждое текстовое сообщение, которое вы добавляете в свой программный продукт, должно быть переведено.
Однажды заказчик добавили в свою программу небольшую функцию, на разработку которой у них ушел всего один день. После того, как они закончили разработку, у нас ушло около трех недель на то, чтобы внедрить эту функцию в реальную программу. Некоторые переводчики-фрилансеры уже были заняты в других проектах и потребовалось дополнительное время, чтобы они могли найти возможность вернуться к нашим задачам. В некоторых странах возникла необходимость в прояснении юридических вопросов. Кроме того, наши переводчики в некотором отношении зависели друг от друга. Как я уже говорил, в качестве исходного языка мы использовали немецкий, но не все наши переводчики владели этим языком. Поэтому в некоторых случаях сообщения на немецком приходилось сначала переводить на английский или русский, а затем с английского или русского на другие языки.
С точки зрения разработчиков, это не так уж плохо. На самом деле это может служить очень хорошим оправданием, если заказчик или менеджер проекта за день до выпуска готовой программы задает вам вопрос, можете ли вы добавить функцию X или Y до завтрашнего дня. Разумеется, вы можете ее добавить, но осуществить ее локализацию до завтра просто невозможно, поэтому лучше запланировать ее в следующей версии программы.