Советы для тех, кто планирует заняться локализацией своего проекта

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

    image

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

    Если вы планируете в ближайшее время локализовать какой-то из своих проектов, то рекомендуем воспользоваться нашим сервисом Lokalise. За три года разработки сервиса мы съели на локализации и переводах не одну стаю собак.
    Lokalise 63,71
    Платформа для локализации и перевода ПО
    Поделиться публикацией
    Комментарии 13
    • +9
      У вас талант описывать очевидные вещи в большое количество предложений ради последнего абзаца.
      • +2
        Ну из-за КДПВ я отправился в долгое и увлекательное путешествие по гугл-картинкам. GTA как-то мимо меня прошло, так уж случилось.
        • 0

          Вторая статья на ХХ, вывод сделали. Спасибо за комментарий!

        • +4
          После прочтения заголовка ждал списка конкретных полезных советов по локализации.
          В итоге получил много невнятной воды ради рекламной ссылки в конце.
          • 0

            Замечание учтём, спасибо!

          • +2
            Исходная статья была на английском и содержала массу дельных и конкретных советов, но в процессе локализации они все трансформировались в последний абзац.
          • 0
            А почему ваш сайт не локализован?
            • 0

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


              Кстати, поддержка на двух языках оказывается, хотя это и недокументированный функционал.

              • 0
                Да, я дублировал этот ответ в поддержку. Собственно, если бы не эта рекламная статья — никогда бы даже не задумался о пользовании этим сервисом
                • 0
                  Возможно, наличие русского языка было не очевидно для пользователя? Что мешает определять язык и предлагать переключиться или остаться? Вообще странно, что подобный сервис не локализован. Думаю, что большинство посетителей испытывают трудности с переводом. Или я ошибаюсь?
                  • 0

                    Это не так важно, ilyapot!


                    1. Пользователей с русским языком у нас пока что ~6%. С французским, немецким и испанским пользователей больше.


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


                    3. Наш сервис автоматизирует постоянный процесс перевода и обновлений в мобильных и веб-приложениях, не на сайтах-визитках. Обычно такие приложения делают разработчики с достаточным английским языком, будь то Россия, Вьетнам или Франция. Если среди них и есть разработчики с трудностями в английском языке, их незначительная часть, и они просто не наши клиенты, откуда бы они не были.
              • 0
                Мы кстати тоже пилим свой опенс-соурс инструмент для управления локализацией. Если интересно, можете поиграться, вот тут: https://github.com/w32blaster/fyzon

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое