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



Будем откровенны: если ваш продукт ориентирован на широкую аудиторию, то английского языка явно недостаточно. Конечно, существуют узкоспециализированные проекты и сервисы вроде нашего, когда знание главного международного языка не прихоть – необходимость, однако ниша подобных разработок крайне узка. И вот, тысячи команд по всему миру рано или поздно упираются в потолок одного-двух языков: один английский, а второй – родной для команды (если она не англоговорящая). Дальше начинаются споры, ссоры, попытки локализации и последующие пляски с бубном.

В этой публикации мы собрали ряд популярных советов и рекомендаций как от частных разработчиков, так и от матерых команд уровня Mozilla, в которых более опытные товарищи делятся со своими коллегами опытом локализации проектов.

Семь раз отмерь

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

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

Как можно понять из текста выше, немалая роль в успешном проведении локализации лежит на дизайнерах. По мнению Standish Group лишь 20% фич и функций проекта обеспечивают его конкурентоспособность, но вот однозначно и объективно выявить эти самые ключевые «точки» самим разработчикам удается не всегда. Поэтому уделять внимание приходится всему и вся, ведь ошибка на критичном для потребителя, но не слишком приоритетном по мнению разработчиков участке проекта может сыграть решающую роль.

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

Важно не только снаружи, но и внутри

Все сказанное выше, по сути — лирика для дизайнеров и проект-менеджеров. Команда же Mozilla, которая имеет весьма солидный опыт в локализации продуктов, дает более развернутые советы для разработчиков.

Например, Mozilla Developer Network в своем блоге рекомендует в ходе разработки обращать внимание на мелочи и в общем быть опрятными. Так, по их мнению крайне важно выбирать адекватные имена для меток (ключей) в ходе локализации и мы, исходя из опыта наших клиентов, согласны с этим утверждением. Метки, вне зависимости от степени важности и роли, «всегда должны описывать строку и ее роль в интерфейсе». Если строка привязывается к какой-то особенной функции или всплывающему окну, то метка должна отражать и эту информацию.

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

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

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

Переводчики — наше все

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

Очень часто локализацией занимаются так называемые «native speakers», или, если выражаться по-русски — носители языка. Коммуникация же происходит либо на языке первоисточника ресурса (если это прямая локализация с какого-то языка, отличного от английского, на какой-то третий язык), либо при помощи того же английского. Многие разработчики забывают, что привычная им англоязычная лексика отличается от общепринятой. Таким образом, общаясь с переводчиком, который не слишком плотно знаком с теми или иными тонкостями профессиональной лексики, могут возникнуть смысловые коллизии.

Банальный пример — bus, bookmark или просто слова, которые в английском имеют несколько значений исходя из контекста (fire, right, set, date и так далее, список крайне длинный). Всегда необходимо помнить, что как минимум один из участников процесса локализации (если вы привлекаете к работе носителей), говорит и пишет на неродном для себя языке. Конечно, есть специалисты, чьи способности позволяют им общаться на уровне носителей сразу на нескольких языках, но это случается крайне редко и не по карману большинству команд. Будьте терпимее к локализаторам и помните, что от того, насколько четко и однозначно вы изъясняетесь с ними, зависит, насколько качественнее будет выполнена работа.

Если вы планируете в ближайшее время локализовать какой-то из своих проектов, то рекомендуем воспользоваться нашим сервисом Lokalise. За три года разработки сервиса мы съели на локализации и переводах не одну стаю собак.

https://habrahabr.ru/post/334178/