5 причин, почему раньше локализация была сплошной головной болью

Локализация мобильных или веб-приложений была раньше сплошной головной болью. Уже давно разработчики ПО оптимизировали все процедуры своей работы. Локализация сегодня — довольно легкая задача в ходе процесса разработки. Но давайте заглянем в прошлое и выявим, в чем были причины прежних трудностей.

Причина №1: работа с файлами

Главной проблемой была пересылка файлов туда-обратно. Приходилось отправлять оригинальные файлы бюро переводов или фрилансерам и ждать, когда все будет готово. Это нужно было проделывать по каждому языку и для каждой части приложения отдельно. Электронные письма уходили в папку «спам», переводчики пользовались провайдерами с ограниченным объемом хранения информации. Между прочим, хранение файлов в электронном ящике — тоже не самый удобный вариант. Поэтому в конце концов специалисты стали прибегать к помощи  Dropbox, сервера FTP… Или вы отправляли DVD?

Второй по жесткости проблемой (тесно связанной с первой) было форматирование. Приходилось либо конвертировать текст в Excel перед отправкой, а затем повторно изменять формат после получения, либо поручать форматирование переводчику или бюро, что зачастую приводило к ошибкам и в результате файл признавался негодным (что обычно происходит с файлами YML или при использовании программ обработки текста с изменением кодировки). Чтобы с этим справиться, требовалось колоссальное количество времени.

Причина №2: отсутствие контекста

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

Причина №3: разные версии документа

Причину №1 усугубляло появление многочисленных версий. Что-то в приложении поменялось, и вот у вас уже новый вариант исходного файла. Отправлять переводчику весь файл или сами изменения? Какой из файлов последний? Как втиснуть в него эти изменения? А кто-нибудь подумал об участи переводчика при этом? Что, если какие-то детали останутся непереведенными, потому что все версии документа смешались и никто не в силах восстановить цепочку происходящего? К примеру, Google Docs облегчило корпоративное редактирование в офисах, позволив уменьшить число файлов, переправляемых членами рабочей группы друг другу. 

Причина №4: работа в команде

Очевидно, вышеперечисленных проблем (не говоря уже о чисто языковых) было недостаточно, потому что для выполнения проекта вовлекали еще больше людей. Сотрудников, рекламщиков, разработчиков пользовательских интерфейсов, одного или нескольких переводчиков, редакторов… Как удержать их всех в одной лодке, как предотвратить проблемы 1, 2 и 3 для каждого из них при работе над локализацией? Это было очень утомительно. В любом случае надо было урезать поток электронных сообщений. Настоящий кошмар начинался тогда, когда копия письма направлялась всем подряд, хотя далеко не все были на самом деле задействованы в конкретном вопросе. Как правильно распределить роли и как их осуществить технически?

Причина №5: собственно масштаб

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

Так что же изменилось? Почему сегодня незачем хвататься за голову, когда дело доходит до локализации? Об этом — в следующей статье.