Как делают локализацию для японского рынка.

• Предоставить механизм переопределения таблицы стилей (чтобы парни-локаторы могли изменять стиль элемента)
• Назначить уникальный идентификатор для каждого элемента отображаемой HTML-страницы (это позволит им нацеливать точное управление с их переопределенным стилем)
• Используйте кодировку UTF-8, где бы вы ни находились (явно HTML-страницы, электронные письма, если они есть, но, возможно, файлы ресурсов (т.е. свойства))

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

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

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

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

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

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

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

И последнее, но не менее важное: типичный способ реализации (это не лучшее слово здесь, потому что у него много других значений). Локализуемость - это просто извлекать строки для некоторых файлов ресурсов (то есть ResourceBundle в мире Java) и сохранять их в отдельном jar (я бы предложил одну банку на язык, названный в соответствии с идентификатором локали, то есть ja.jar, de.jar, fr-CA.jar). Файл jar также должен содержать дополнительный файл CSS (содержимое которого будет использоваться для переопределения определенных стилей). Все остальное, что вы найдете в моем предыдущем ответе...

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

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

Немного о терминах
Строго говоря, сайты не переводят, а локализуют. Локализация - это не просто перевод с одного языка на другой. Это комплексная адаптация к культуре и реалиям рынка, в результате которой тексты на сайте, графика, мультимедиа, верстка - все выглядит так, как этого ожидает целевая аудитория. Именно поэтому очень важно учесть множество нюансов, в том числе таких, которые на первый взгляд могут показаться незначительными. К примеру, подумать о длине слов в целевом языке (в английском они короче, чем в русском, а в немецком - длиннее) уже на этапе проектирования интерфейса. Например, «выход» и «exit» ещё не так сильно отличаются, а вот немецкий «Beenden» и китайский 退出 уже тянут на задачку для дизайнеров интерфейса.

Качество перевода сайта
Сайт - это лицо компании. У пользователей нет возможности попробовать продукт. Отношение к нему рождается на основе UX и восприятия текста - информативности, стиля изложения, грамотности.

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

Процесс оценки выглядит так: специалист изучает перевод и фиксирует ошибки в специальной форме, попутно классифицируя их. После этого он по специальной формуле вычисляет «индекс качества» в диапазоне от 0 до 100. При трехступенчатой технологической схеме (переводчик, редактор и корректор), рекомендованной для локализации сайтов, ПО и маркетинговых материалов, этот показатель должен быть не ниже 90.

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

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

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

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

ТЗ для перевода
Базовое ТЗ описывает, что переводить, для какой аудитории, на какие языки, за какой срок и в каком формате необходим результат. Поскольку на его основе считается стоимость перевода, решите, какой контент нужно переводить, а какой нет. К примеру, можно обойтись без архива новостей за давно прошедшие годы: его локализации может обойтись недешево, при этом существенную пользу на новом рынке он даст далеко не во всех случаях.

Иногда сходу сложно отделить важное от неважного - например, если речь идёт о больших интернет-ресурсах и десятках тысяч страниц, накопленных за годы работы. Переводческие компании в таких случаях анализируют карту сайта, делают детализированный расчет объемов и стоимости по всем разделам и страницам. Такой отчет помогает понять, где накопилось много контента, и принять взвешенное решение, что переводить, а без чего можно обойтись.

Исходники
Наличие исходных файлов (html, xml, doc, xls или других) упрощает и удешевляет локализацию, а также экономит силы и нервы - вы спокойны, что исполнители точно не переведут лишнего и ничего не забудут.

Скидывать исполнителям ссылку на ваш сайт с пометкой «перевести до среды» - не самый эффективный способ постановки задачи, хотя и он работает. Лучше укажите, что именно перевести, и дайте доступ к CMS сайта, чтобы исполнители сразу работали с исходными файлами.

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

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

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

Как бывает в жизни

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

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

Если нужно перевести маркетинговые тексты для запуска продукта, настоятельно рекомендуем дополнительно привлекать редактора-рерайтера. Он адаптирует переведенный текст и правильно расставит акценты. Могут потребоваться и другие работы: перерисовка изображений, изменение шаблона страницы и пр.

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

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

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

Переводчик работает с машинным переводом

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

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

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

Что делать, если бюджет на локализацию небольшой, а переводить сайт все равно нужно
Сэкономить на локализации помогут:

• Технологии автоматизации переводческого процесса. Целый класс программ, CAT-инструменты (Computer-Aided Translation - системы автоматизации процесса перевода), помогают повторно использовать ранее переведенные слова и фразы и облегчают труд переводчиков. Это не машинный перевод, а тексты, созданные человеком (профессиональными переводчиками). В CAT-системах используется накопленная память переводов и проектный глоссарий. Важно, чтобы переводчики использовали наиболее актуальные лингвистические ресурсы. Например, в платформе SmartCAT они сразу же становятся доступны всем участникам процесса, что особенно ценно, когда на большом проекте параллельно работает несколько переводчиков.
  
  Параллельная работа нескольких переводчиков над одним текстом
• Расчет стоимости локализации по словам оригинального текста. В статистику не попадут куски кода и другая служебная информация, а стоимость перевода не увеличится после его выполнения, чем иногда страдают недобросовестные подрядчики.
• Организация работы по частям. Если сайт большой, содержит множество описаний продуктов или услуг - разбейте работу на этапы. Сначала переведите наиболее критичные страницы, которые позволят вам начать привлекать клиентов на новом рынке уже сейчас. Постепенно расширяйте объем контента по мере того, как объем продаж на этом рынке будет расти. Этот подход также позволит постепенно накапливать память переводов, а значит, все последующие тексты можно будет перевести быстрее и дешевле, с сохранением единства терминологии и стиля.

1. Писать длинные, тяжеловесные фразы, наполненные причастными и деепричастными оборотами. Пишите проще, используйте глаголы, не обращайтесь к пользователям на «Вы», следуйте заветам Максима Ильяхова .
2. Использовать безличные обращения. В некоторых языках они не употребляются, как и дополнительные формы вежливости. Поэтому смело отказывайтесь от них.
3. Применять одну схему построения фразы для каждой языковой версии сайта. Например, для фраз с переменными вида «До конца подписки осталось X дней». В русском языке в зависимости от числа будет меняться падеж и число: дней, дня, день. В других языках может потребоваться предлог или изменение фразы. Имеет значение и плейсхолдер, и двоеточие: например, в турецком фраза начнется с цифры.
Добавить метки

Ник Устинов, генеральный директор сервиса по автоматизации переводов мобильных приложений и веб-сервисов , рассказывает, как локализация влияет на прибыль онлайн-бизнеса.

Все читали Котлера, все слышали про маркетинг. Ладно, читали не все, но слышали про него точно. Сегментируй, докапывайся до микросегментов, а потом предлагай продукт именно для этой аудитории. Так вот, Байрон Шарп, директор Института маркетинговых наук Эренберга-Басса при Университете Южной Австралии, десять лет изучал этот вопрос и доказал обратное . Если вы хотите зарабатывать много, нужно товар или услугу предлагать всем. Целевой сегмент будет часто ей пользоваться, но именно нерегулярное потребление большим количеством покупателей принесет до 50% прибыли.

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

Зачем вообще локализовывать ваше приложение? Если вы предоставляете услуги для очень небольшой территории, например, у вас химчистка, куда носят одежду жители одного района, то локализация вам вроде как ни к чему. Разумеется, тут же найдутся умники, которые скажут, что в районах Лондона, Парижа или Рима живут люди, которые общаются на разных языках, но здесь речь не об этом.

Изображение: Giphy

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

Причина 1: деньги

В блоге и на -канале Android Developers есть немало кейсов о влиянии локализации на доход. Например, стартапу Noom, выпускающему приложения для здорового образа жизни, локализация принесла +80% к прибыли на . Причем в локализации был не только перевод, но и интернационализация контента. Еще один пример - аргентинский стартап Papumba, делающий приложения, которые учат детей узнавать звуки различных животных. Дети - прекрасный пример аудитории, которая не знает английского и не выучит его в ближайшие пару лет. Для Pаpumba локализация на 15 языков увеличила рост установок на 300% . Подобное расширение верхнего уровня воронки - настоящая мечта стартапа. Далее они занялись интернационализацией: убрали тех животных, которые вызывали негатив в определенных странах. Например, в мусульманских странах из приложения убрали свинью. После этих мер рейтинг приложения в Google Play увеличился с 3,9 до 4,2, что опять же, заметное улучшение, особенно если учесть, что для таких изменений не потребовалось значительное количество ресурсов.

Часто, как аргумент для локализации приводится статистика о распространенности языков. Мол, сейчас очень много испанского, упрощенного и традиционного китайского, а также растет сегмент португальского языка (в особенности бразильского диалекта). Но ведь многим хватает и английского. Насколько увеличится прибыль, если сделать локализацию?

Изображение: Giphy

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

Polybius - проект по созданию регулируемого банка для цифрового поколения. В рамках ICO он собрал $31 млн в различных фиатных и криптовалютах. В общей сложности проект был локализован на десять основных языков, включая даже корейский, японский и китайский.

Depositphotos - один из крупнейших международных фото- и видеобанков, в коллекции которого насчитывается более 67 млн файлов. Локализован на 20 языков, сейчас ведется работа еще над двумя, казалось бы, экзотическими версиями - тайской и индонезийской.

Nimses - геолокационное приложение, которое позволяет превращать время пребывания в сети в «нимы» - валюту, которую можно обменивать на товары или услуги. Сейчас в сервисе представлены все языки стран Европы, приложение доступно в 70 странах мира, в том числе в Латинской и Северной Америке. Его аудитория стремительно растет и на сегодня составляет порядка 3 млн пользователей (хоть приложение вышло совсем недавно). Язык интерфейса в приложении определяется автоматически, в зависимости от того, какой язык определен в настройках телефона. Если же там установлен язык, который не поддерживается, то по-умолчанию Nimses будет на английском.

Причина 2: глупо делать одну работу дважды

В идеале курс на локализацию нужно брать еще на этапе Hello world. Раз создав структуру ключей с переводами разных элементов интерфейса и выделив место под интернационализацию на сервере, потом можно будет масштабировать приложения на новые рынки фактически без привлечения разработки. Это заметно проще и, главное, дешевле, чем делать 1.0 и впихивать перевод хардкодом, а потом переписывать структуру приложения, когда CEO становится очевидно, что он просто недополучает десятки-сотни процентов доходов на других рынках.

Изображение: Giphy

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

Причина 3: мультиплатформенность

Речь не только про iOS-версию вашего Android-приложения. Если вы поддерживаете одновременно и приложение для смартфона, и сайт, и, упаси вас Джобс, еще и приложения для консолей, Smart TV или носимых гаджетов, то придется следить за тем, чтобы в каждом из устройств все интерфейсные и контентные элементы были одинаковыми. Иначе ваш UI/UX-гуру будет очень страдать и убеждать вас, что пользователь не должен гадать, почему на сайте раздел называется «Профиль», а в смартфоне – «Аккаунт». Переходы пользователя по разделам/уровням игры или его любое другое целевое действие должны быть простыми и интуитивно понятными на каждом устройстве.

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

Пример работы Lokalise.

И это не означает, что в коде ваших приложений для разных платформ придется придерживаться каких-то специфических принципов написания.

С помощью того же Lokalise, в приложениях это могут быть разные переменные, которые на серверной стороне объединены в один ключ. То есть LikeButton в коде под iOS и like_button в коде Android могут быть подвязаны под один ключ перевода, и будут идентично переведены в каждой из локализаций.

Причина 4: оптимизация ресурсов

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

(Так, средняя стоимость перевода слова по рынку составляет 10 центов. Возьмем условно проект из 1000 уникальных слов на двух платформах. Так вот, перевод на один язык займет 1-2 дня и обойдется в 100 долларов).

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

11.02.2016
19.03.2018

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

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

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

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

В общем виде подключение языковых фраз выглядит, примерно, так:

Use \Bitrix\Main\Localization\Loc as Loc; Loc::loadMessages(__FILE__); Loc::getMessage("MSG_KEY");

Начинающие разработчики 1С-Битрикс (хотя и многие уже достаточно опытные разработчики тоже) все оставляют кирилицу прямо в шаблоне, считая, что потом, позже, перенесут. И так и остается вся эта каша на годы в шаблоне. Хорошо, если сайт в одной языковой версии устраивает своих посетителей годами и производить его локализацию нет необходимости, а че если нет, как говорит Семен Слепаков? Поэтому приучайте себя всегда выносить кирилицу в языковые фразы. Не вы, так кто-то другой обязательно выразят вам за это свою благодарность.

Теперь считаем, что вся кирилица хранится в языковых фразах и перевод не будет столь уж сложным. Для того, чтобы вытянуть все языковые фразы для перевода воспользуемся модулем "Перевод" системы 1С-Битрикс (обладателям редакций без данного модуля придется писать скрипт, который за вас вытянет все языковые файлы и сформирует CSV-файл).

Открываем в админке Настройки - Локализация - Просмотр файлов. В поле "Путь" вписываем относительный путь до шаблона сайта. Ниже выбираем вкладку "Выгрузка файла" и на ней - "Выгрузить все переводы". Нажимаем "экспортировать". Таким образом получили CSV файл, состоящий из такого набора колонок:

"file"; "key"; "ru"; "ua"; "en"

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

Файл кладем где-то в системе (я обычно помещаю в upload), а в нашем скрипте-обработчике сразу добавляем первую фразу с указанием полного, абсоллютного пути до файла:

$fileName = $_SERVER["DOCUMENT_ROOT"] . "/upload/bitrix_templates_template.csv";

И файлик, в который запишем результат:

$fileName = $_SERVER["DOCUMENT_ROOT"] . "/upload/bitrix_templates_template_res.csv";

Require_once($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/classes/general/csv_data.php");

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

Function csv_to_array($filename="", $delimiter=",") { if(!file_exists($filename) || !is_readable($filename)) return FALSE; $header = NULL; $data = array(); if (($handle = fopen($filename, "r")) !== FALSE) { while (($row = fgetcsv($handle, 1000, $delimiter)) !== FALSE) { if(!$header){ $header = $row; foreach ($row as $key=>$value) { if (strlen($value) > 0)$header[$key] = GetTranslitCode($value); } } else { foreach ($row as $key=>$value) {$row[$key]=$value;} $data = array_combine($header, $row); } } fclose($handle); } return $data; }

GetTranslitCode - это обертка вокруг обычной битриксовой функции транслитерации:

Function GetTranslitCode($text) { $text = trim($text); if (strlen($text) "-", "replace_other" => "-", "delete_repeat_replace" => "true", "use_google" => "false",); return CUtil::translit($text, "ru", $params); }

Прогоняем наш csv-файл через обработку csv-файла и получаем ассоциативный массив из строк файла с заголовками в виде ключей:

$arRows = csv_to_array($fileName, ";");

Создаем с перезапись результирующий файл:

$fp = fopen($resFileName, "w+"); fclose($fp);

Записываем сразу в результирующий файл заголовки:

$csvFile = new CCSVData(); $fields_type = "R"; $delimiter = ";"; $csvFile->SetFieldsType($fields_type); $csvFile->SetDelimiter($delimiter); $arrHeaderCSV = array("file", "key", "ru", "ua", "en"); $csvFile->SaveFile($resFileName, $arrHeaderCSV);

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

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

$translator = new Yandex_Translate("ключ, полученный тут: api.yandex.ru/key/form.xml?service=trnsl"); $srPresent = array(); foreach ($arRows as $num => $row) { if(strlen($row["ru"])yandexTranslate("ru", "uk", $row["ru"]))->text; $row["ua"] = $text; $srPresent[$row["ru"]] = $row["ua"]; } } $csvFile->SaveFile($resFileName, array($row["file"],$row["key"],$row["ru"],$row["ua"],$row["en"])); }

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

Для загрузки языковых фраз снова открываем в админке Настройки - Локализация - Просмотр файлов. В поле "Путь" вписываем относительный путь до шаблона сайта. Ниже выбираем вкладку "Загрузка файла" и на ней выбираем наш файл, выбираем направление перевода "полностью заменить..." (или только новые, если вы делали частичный перевод) и нажимаем "Импортировать"

Все! Теперь языковые фразы созданы и можно спокойно заниматься реализацией второй локализации сайта.

В процессе проработки данного механизма были использованы материалы:

UPDATE 2016-02-23

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

Для значений свойств этот недостаток можно обойти с помощью свойства типа "Справочник", заполняя UF_NAME основным языком, а другое поле (например, UF_DESCRIPTION) - забираем под второй язык. Но этого нельзя сделать для названий свойств - нет поля, в котором это хранить.

Из всей этой проблемы родилось решение: Создал отдельный языковой файл props.php, который подключил рядом с языковым файлом хедера:

If(LANGUAGE_ID=="ua"){ Loc::loadMessages($_SERVER["DOCUMENT_ROOT"].SITE_TEMPLATE_PATH."/props.php"); }

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

Function GetFromVacabulary($filterEntity, $filterValues,$arSelect = array("ID", "UF_NAME", "UF_XML_ID","UF_DESCRIPTION")) { if(!is_array($filterEntity) || empty($filterEntity)) return false; $cacheParams = array("filterEntity" => $filterEntity, "filterValues" => $filterValues, "lang" => LANGUAGE_ID); $cache_id = md5(serialize($cacheParams)); $cache_dir = __CLASS__ . "/" . $cacheParams["module"]; $obCache = new CPHPCache; if ($obCache->InitCache(36000, $cache_id, $cache_dir)) { $arResult = $obCache->GetVars(); $arResult["CACHE"] = "Y"; } elseif (\Bitrix\Main\Loader::includeModule("highloadblock") && $obCache->StartDataCache()) { if(LANGUAGE_ID=="ua"){ $translator = new \Yandex_Translate($this::YANDEX_TRANSLATOR_KEY); } global $CACHE_MANAGER; $CACHE_MANAGER->StartTagCache($cache_dir); $hlblock_requests = \Bitrix\Highloadblock\HighloadBlockTable::getList(array("filter" =>$filterEntity))->fetch(); if (!isset($hlblock_requests["ID"])) return false; $entity_requests = HL\HighloadBlockTable::compileEntity($hlblock_requests); $entity_requests_data_class = $entity_requests->getDataClass(); $main_query_requests = new Entity\Query($entity_requests_data_class); $main_query_requests->setSelect($arSelect); if (!empty($filterValues)){ $main_query_requests->setFilter($filterValues); } $result_requests = $main_query_requests->exec(); $result_requests = new CDBResult($result_requests); $arResult["ITEMS"] = array(); while ($row_requests = $result_requests->Fetch()) { if(LANGUAGE_ID=="ua"){ if(strlen($row_requests["UF_DESCRIPTION"])>0){ $row_requests["UF_NAME"] = $row_requests["UF_DESCRIPTION"]; } else { $text = json_decode($translator->yandexTranslate("ru", "uk", $row_requests["UF_NAME"]))->text; $text["ua"] = $text; $row_requests["UF_NAME"] = $text["ua"]; $entity_requests_data_class::update($row_requests["ID"],array("UF_DESCRIPTION"=>$text["ua"])); } } $arResult["ITEMS"][$row_requests["UF_XML_ID"]] = $row_requests; $CACHE_MANAGER->RegisterTag("hl" . $cacheParams["entity_id"] . $row_requests["UF_XML_ID"]); } $CACHE_MANAGER->RegisterTag("hl" . $cacheParams["entity_id"]); $CACHE_MANAGER->EndTagCache(); $obCache->EndDataCache($arResult); } else { $arResult["ITEMS"] = array(); } return $arResult; }

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

$putLinesToLangFile = ""; foreach ($arResult["ITEMS"] as $key=>$arItem) { if($arItem["PROPERTY_TYPE"]=="S" && $arItem["USER_TYPE"]=="directory"){ $tmp = $mainEntity->GetFromVacabulary(array("TABLE_NAME"=>$arItem["USER_TYPE_SETTINGS"]["TABLE_NAME"]), array("UF_XML_ID"=>array_keys($arItem["VALUES"]))); if(!empty($tmp["ITEMS"])){ foreach ($tmp["ITEMS"] as $hl_code => $hl_val) { $arItem["VALUES"][$hl_code]["VALUE"] = $hl_val["UF_NAME"]; } } } if(strlen(Loc::getMessage($arItem["CODE"]))>0){ $arItem["NAME"] = Loc::getMessage($arItem["CODE"]); } else { $arItem["NAME"] = $mainEntity->TranslateText($arItem["NAME"]); $putLinesToLangFile .= "$MESS["".$arItem["CODE"].""] = "".$arItem["NAME"]."";".PHP_EOL; } $arResult["ITEMS"][$key] = $arItem; } if(strlen($putLinesToLangFile)>0){ $current = file_get_contents($_SERVER["DOCUMENT_ROOT"].SITE_TEMPLATE_PATH."/lang/ua/props.php"); $current = substr($current,0,-2).$putLinesToLangFile."?>"; file_put_contents($_SERVER["DOCUMENT_ROOT"].SITE_TEMPLATE_PATH."/lang/ua/props.php", $current); }

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

На основании символьного кода свойства проверяем наличие языковой фразы - если фразы нет, то производим автоматический перевод с помощью Яндекс.Переводчика и Записываем полученный результат в заготовку для записи в языковой файл. Далее, когда все свойства перебраны в языковой файл производим запись полученных языковых фраз: считываем наш кастомный языковой файл и дописываем в него новые фразы.

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