Локализация ПО и документации: тест-кейсы и часто задаваемые вопросы

1. Дешевле всего работать с популярными редактируемыми форматами, которые можно просто импортировать в локализационную платформу и сразу работать. К таким форматам относятся файлы Microsoft Office (docx, xlsx, pptx и т. д.), Google Document/Sheets/Slides и обычные текстовые форматы (txt, html, xml, po). 
2. Иногда файлы бывают редактируемыми, но локализационная платформа их не знает. Например, к таким относятся файлы Figma, Corel Draw, Adobe Photoshop, Adobe Illustrator, Adobe Indesign, Autodesk Autocad. В таких случаях мы либо экспортируем проприетарные форматы в обычные (и обратно), либо ищем нужные коннекторы, интеграции или конвертеры, которые позволят это делать в двух направлениях. 
3. Самые проблемные: нередактируемые форматы (особенно с градиентами на заднем фоне), например, pdf, jpg, png. Для работы с такими форматами приходится добавлять операции с привлечением наборщиков, верстальщиков, корректоров и т.п. для извлечения текста, размещения готового перевода обратно в макет, для проверки финального качества и локализационного тестирования.

В целом мы всеядны насчет форматов. У нас в портфолио есть проекты, где нам клиент дает просто ссылку на ролик в Youtube на английском, а в итоге получает озвученный ролик в Youtube на русском или готовую к публикации статью на русском в учетке Хабра/блоге клиента. 

1. Иногда заказчик интегрирует разработку своего продукта с определенной локализационной платформой (SmartCAT, Wordfast Anywhere, Locize, Matecat), и для того, чтобы команда переводчиков бесшовно встроилась в непрерывную локализацию продукта и локализационное тестирование, требуется чтобы она изучила функциональные возможности нужной платформы. 
2. Наиболее экономичен вариант, когда локализационная платформа уже хорошо известна команде переводчиков. В нашем случае это SmartCAT, команда может приступать к работе в ней немедленно. 
3. Важно, чтобы платформа предусматривала разные роли участников процесса: были неудобные случаи, когда переводчик не видел, проверил ли его перевод редактор или нет — платформа никак не показывала внесенные редактором правки или отметки о приемке перевода. 

1. Вы даете нам ссылку на свой макет/страницу/фрейм в Figma/Github (Bitbucket и др). 
2. Мы дублируем его в свое пространство (делаем fork) и программно экспортируем текстовые слои (исходный текст). 
3. Слои (текст) импортируем в свою платформу, работаем с ними, выгружаем, и вносим в свое пространство. 
4. Тестируем, если все ОК, даем вам ссылку на нашу версию макета в Figma (делаем пулл-реквест в GitHub). 
5. Вы дублируете перевод его в свое пространство и работаете с ним. 
6. Если есть замечания/вопросы, вы их сообщаете нам через Figma/Github или иным удобным вам способом. Мы их изучаем, по необходимости вносим правки. 

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

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

Следует учитывать, что канал распространения накладывает некоторые ограничения на оформление текста. 

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

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

По-хорошему, скриншоты надо переделывать на целевом языке; вопрос только в том, кто это будет делать — сотрудник клиента или кто-то из нашей команды.  Если нам дают доступ к админке сайта или демонстрационному стенду продукта, то скриншоты можем переснять мы, а затем встроить их в документацию. 

1. Если элементы интерфейса внесены в макет Figma, то см. вопрос про работу в Figma. 
2. Если элементы интерфейса «зашиты» в код/ресурсные файлы продукта, то их нужно либо экспортировать в текстовый формат (*.po, *.csv, *.xml и т. д.) + предоставить нам доступ к интерфейсу продукта или админке раздела сайта (с учетом роли пользователя). Нам это нужно для учета контекста. 
3. Если есть ограничения по длине строк или, например, по кодировке
4. Мы переводим/локализуем строки, выгружаем файл с переведенными строками. 
5. Этот файл применяет либо клиент, либо мы (если есть доступ), и мы проверяем итоговый результат (корректен ли перевод, не наезжают ли друг на дружку строки в десктопной и мобильных версиях и т.д.; не вылезают ли строки за пределы отведенного им поля и т. д.). 

Даты в разных странах пишутся по-разному, где-то на первом месте ставится месяц, где-то год (иными словами, 9.5 для одних будет 9-е мая, для других 5-е сентября). Соответственно, нам нужно понимать, под какую конкретно страну мы переводим. Впрочем, иногда клиенты предпочитают использовать универсальный формат, при котором, во избежание недоразумений, месяц пишется прописью, типа «May 9, 2023». 

1. Валюты обычно пересчитывают с локальной на глобальную (например, рубли на доллары), или наоборот; реже с локальной на локальную. 
2. Валютный значок в зависимости от страны ставят в разные места: где-то принято писать 1 €, где-то € 1. Помимо страны тут нужно учитывать, что при обработке изменение формата представления может нарушить работу приложения. 

1. Иногда клиентам при переводе нужен перевод в британскую/американскую систему мер (сантиметры в дюймы, градусы Цельсия в градусы Фаренгейта) или из нее, иногда нет. 
2. Кроме того, даже если заказчик просит локализовать единицы измерения, в некоторых случаях от такой локализации целесообразно отказаться (например, размер жесткого диска или диагонали монитора даже в России обычно измеряют в дюймах). 

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

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

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

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

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

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

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

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

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

Иногда в материалах заказчика попадаются ссылки на разные информационные источники (например, Wikipedia или база знаний Microsoft); если материал на английском, то и ссылки обычно ведут на англоязычные материалы. 

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

1. При локализации вебсайта и разработке мероприятий по его продвижению на внешнем рынке, его ключевые слова (SEO) требуется переводить с учетом продуктового ландшафта и поисковой специфики  целевого региона.
2. У некоторых поисковых запросов может вообще не быть аналогов, а для некоторых может быть несколько вариантов. 
3. Для анализа поисковых запросов используются инструменты подбора ключевых слов поисковых машин (например, wordstat.yandex.ru)

1. В книге Эрин Мейер «Карта культурных различий» автор анализирует стиль коммуникации у русских и американцев. Русских автор отнесла к культурам, которые предпочитают сразу переходить к сути дела, без предварительного, вводного контекста, а американцев — к культурам, которые предпочитают всегда проговаривать вводный контекст, а потом, после объяснения материала, подытоживая, повторно проговаривать сказанное. 
2. Как следствие, американская манера передачи информации раздражает русского читателя. Справедливо и обратное.
3. Заказчики иногда просят этот момент учитывать в англо-русском переводе и исключать ненужные повторы одной и той же мысли разными словами. 

Есть и другой аспект, который тоже нужно учитывать при локализации. 

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

Дело в том, что иногда в документации нумерацию списков делают буквенной: a), b), c) или а), б), в). При переводе с одного языка на другой возникает вопрос — надо ли переделывать литеры? Если на них перекрестных ссылок нет, то заменить литеры можно безболезненно. 

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

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

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

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

С этим учетом одни и те часы работы офиса в Москве могут отображаться как «10:00 – 20:00» так и «7am – 5pm GMT» . 

При локализации промоматериалов с указанием соцсетей нужно учитывать, что в зависимости от географического региона, нужно будет указывать разные соцсети. В частности, в России популярны Телеграм, ВКонтакте, Одноклассники, а в США — Twitter, Facebook, Instagram. Следовательно, помимо изменения формулировок, нужно будет еще и предусмотреть и замену на другие пиктограммы.