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



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

Храните видимые для пользователя строки отдельно

Определенно самое важное (и самое игнорируемое) правило подготовки к локализации — отделение всех видимых для пользователя строк от кода, который использует их.

Обычный в этом случае подход — хранить текстовый контент продукта в отдельных файлах ресурсов для каждой платформы или языка. Например, Java-программистам стоит держать свои отображаемые строки в файлах ResourceBundle.

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

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

Учитывайте, что отображаемые строки могут стать длиннее или короче

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

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

Используйте изображения без текста

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

Учитывайте отличия в форматах календаря, времени, телефонных номеров и валютных систем

Пишущие код разработчики должны всегда помнить, что другие страны могут:

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

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

Всегда используйте установленные международные стандарты хранения данных. Например, пользуйтесь E.164 для телефонных номеров, ISO-8601 — для временных меток, ISO 639.2 — для языков, ISO 3166 — для стран и tz database — для часовых поясов.

Избегайте ASCII, используйте Unicode

В прошлом разработчики, создававшие софт для исключительно англоязычных рынков, спокойно внедряли в свой код приемы, которые работали только при использовании кодировки ASCII. Например, изменение одного бита в алфавитном символе из ASCII переключало его регистр с нижнего на верхний. Однако с тех пор потребности мира давно превысили возможности ASCII, и теперь Unicode принят как правильный способ кодирования текстовых данных и поддержки международных символов.

Даже при некоторой совместимости Unicode с ASCII лучшим способом избежать проблем с кодировкой строк остается соблюдение этих правил:

• никогда не допускайте кодирования символов в ASCII;
• никогда не полагайтесь на то, что один байт равен одному символу;
• всегда используйте поддерживающие Unicode шрифты и библиотеки.

К счастью, некоторые из самых популярных на сегодняшний день языков программирования, таких как Java, C# и Objective-C, содержат встроенную поддержку Unicode в строковых типах. Их использование превращает решение проблемы международных символов в обычное дело.

Даже если приложение полностью поддерживает Unicode, вероятно, оно хранит данные в базе данных, и плохая логическая структура данных может легко разрушить всю отлично выполненную в коде работу по совместимости с международными кодировками. Например, в базе данных SQL Server отображаемые строки должны храниться в типах nvarchar, а в MySQL лучше всего использовать utf8mb4.

Подробнее о Unicode можно прочесть в хорошей вводной статье Джоэля Спольски.

Учитывайте, что текст не всегда читается слева направо

Самое распространенное различие в отображении текста — написание справа налево, как в арабском языке и иврите.



В веб-приложении основные проблемы, которые возникают при переводе на читающиеся справа налево языки, можно решить простым изменением CSS-свойства direction для всей системы.

Случается также, что текст читается сверху вниз, хотя и гораздо реже.

Видимый для пользователей текст должен быть простым

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

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

Тестируйте базовую поддержку многоязычности

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

Например, представим себе веб-приложение для заказа билетов на концерты. Допустим, уже написан тест, чтобы проверить, может ли пользователь с ненастоящим именем «Иван Иванов» забронировать себе место и убедиться, что его имя правильно отображается на билете, который он получит после оплаты. Добавление простого теста, который меняет имя пользователя на «Иван-??? Иванов-???» и отслеживает, чтобы те же символы отобразились на билете после оплаты, позволит удостовериться в том, что поддержка международных символов работает и в приложении, и в базе данных. Этот простой подход (иногда называемый «псевдолокализацией») позволяет разработчикам проверить, поддерживает ли их приложение передачу и хранение строк с международными символами, без необходимости заказывать полный профессиональный перевод продукта или основательных языковых познаний у самих разработчиков.

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

Охватывайте глобальные возможности

Разработка софта, готового для международного использования, не настолько сложна, как может показаться или какой она когда-то была. Следуя этим простым правилам и делая чуть больше работы вначале, вы можете создавать программные продукты, впоследствии пригодные для использования на гораздо больших рынках, чем вы планировали. А значит, ваш полезный продукт станет доступнее!

Мы же в Alconost всегда рады помочь вам с профессиональной локализацией вашего софта — быстро и качественно.