В последние годы на биржах, связанных с разработкой ПО, локализацией и переводами, все чаще можно встретить проекты по лингвистическому тестированию ПО и мобильных приложений. Что это за лингвистическое тестирование и зачем оно нужно разработчикам?
Лингвистическое тестирование (или LQA) — это этап, который серьезное переводческое агентство обязательно проводит после локализации софта, приложения, сайта. На этом этапе специалист по лингвистическому тестированию проверяет результаты локализации в уже рабочей (или тестовой) среде, то есть именно так, как увидит конечный пользователь приложения (или сайта) на соответствующем языке.
К сожалению, очень часто разработчики мобильных приложений и веб-сайтов заказывают локализацию своих приложений и контента, заменяют в исходных файлах русский текст на английский или наоборот и думают, что все в порядке. Но, к сожалению, это далеко не всегда так.
Например, текст на русском языке часто значительно длиннее такого же текста на английском, так что он может просто не влезть в отведенное для него поле или на кнопку. Это, конечно, не лучшим образом сказывается на интерфейсе: элементы растягиваются, закрывают друг друга, обрезаются. Это самая распространенная проблема, но она и решается проще всего: сокращаешь лишнее, делаешь текст более лаконичным — и проверяешь, что все в порядке.
Бывают и более сложные ситуации, когда какие-то проблемы с локализацией можно заметить только в рабочей среде: например, два соседних пункта меню будут переведены по-разному (например, «Копирование» и «Вставить» вместо «Копировать» и «Вставить») или, наоборот, на одной странице появятся две одинаковые или почти одинаковые кнопки («Отменить» и «Отмена» в качестве переводов для Undo и Cancel, причем это вполне реальная история из жизни). А еще я однажды видела кнопку «Хорошо» вместо ОК. Причем, что характерно, в собственном интерфейсе Apple!
Наконец, переводческие агентства, которые занимаются демпингом для привлечения новых заказчиков, часто нанимают для своих проектов неквалифицированных переводчиков без опыта, а то и вовсе используют машинный перевод. И в результате на выходе мы получаем интерфейс, в котором не соблюдаются отраслевые стандарты локализации, никто не представляет даже, какие источники считать релевантными для проверки, где узнать, как что переводит Apple, а как — Google (ведь часто нужно ссылаться на интерфейсы их устройств).
Такие проблемы может решить лингвистическое тестирование готового интерфейса. Обычно его выполняет переводчик, который давно занимается локализацией, накопил соответствующий опыт, набил руку и может заметить проблему и предложить для нее адекватное решение.
По сути, человек, который занимается лингвистическим тестированием, – это продвинутый пользователь, говорящий на интересующем вас языке: он просто выполняет все функции приложения одну за одной (интуитивно или в соответствии с предоставленным разработчиками планом тестирования), находит проблемы, описывает и отправляет разработчикам на исправление.
В идеале он работает в тесной связке с разработчиками: создает баги, например, в JIRA в соответствии с определенным шаблоном (что не так, почему, как должно быть, скриншот с указанием проблемы), а разработчики либо исправляют, либо объясняют, почему исправить невозможно, и предлагают альтернативное решение.
Очевидно, что выполнять лингвистическое тестирование нужно сразу на всех платформах, которые поддерживает приложение: на iPhone (и iPad при необходимости), на Android и десктопе. Часто баги будут повторяться для разных платформ, но некоторые могут быть уникальными для конкретного устройства.
Желательно, конечно, чтобы специалист, который выполняет лингвистическое тестирование, понимал хотя бы азы программирования: например, не предлагал бы взять и уменьшить немножко шрифт для конкретного поля именно для русского языка, потому что это невозможно, а знал бы, что нужно предлагать более короткий текст, если есть такая возможность. А если нет, то настаивал бы на уменьшении шрифта для всех языков.
И, наконец, если человек уже накопил опыт в лингвистическом тестировании, то он может находить не только лингвистические, но и функциональные баги, а иногда и давать рекомендации по UI и UX в целом. Думается, что дополнительная пара наметанных глаз никогда не помешает. А возможность избежать шуток пользователей над вашим интерфейсом и текстами в социальных сетях – отличный повод для того, чтобы не экономить на этапе LQA.
Я занимаюсь лингвистическим тестированием больше пяти лет (а локализацией и переводами – больше двадцати), в моем портфолио проекты по лингвистическому тестированию разных продуктов, например, Apple и Twitter. Для своего блога я собираю забавные и ужасные примеры локализации интерфейсов и буду очень признательна, если пользователи Хабра согласятся со мной ими поделиться.
P.S. А эта фотография – пример, когда разработчики Quip наняли хороших переводчиков (я, собственно, и занималась локализацией), но отказались от лингвистического тестирования. И мне все равно потом было ужасно стыдно, хотя все было переведено абсолютно верно. Если у вас есть что-то подобное, то мне это очень надо.
