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

К счастью в Android существует достаточно эффективный встроенный механизм для решения этой задачи.

Описание процесса локализации приложений приведено на примере Android Studio 2.3

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

Для этого нужно щёлкнуть правой кнопкой мыши на папке app в дереве проекта и в выпадающем меню выбрать New – Android Resource File. В открывшемся окне следует выбрать пункт Locale с помощью кнопки «>>» или двойного клика мышью.

В результате откроется список доступных языков. При выборе языка к имени папки с ресурсами в поле «Directory name» будет автоматически добавлен соответствующий суффикс.

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

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

Имя файла локализации (поле «File name») необходимо задавать вручную. Настоятельно рекомендуется следовать стандартам Android и называть файлы локализаций strings. Конфликта имён это не вызовет, так как вновь созданные файлы будут находиться в отдельных папках, вложенных в папку Values.

Что касается файла strings.xml, который присутствует в папке Values изначально. После добавления локализаций, строковые значения из него будут использоваться по умолчанию, если для текущего языка, установленного в системе локализация отсутствует.

Само описание локализации абсолютно аналогично «обычному» strings.xml. Единственное отличие в том, что значения строковых ресурсов указываются на соответствующем языке.

Ниже приведён простейший пример.

Содержимое файлов strings.xml используемого по умолчанию и для английской американской локализации:

Multilanguage Application Hello World!

< resources > < string name = "app_name" > Multilanguage Application < / string > < string name = "hello_world" > Hello World ! < / string > < / resources >

Скриншот приложения:

Содержимое файла strings.xml для русской локализации:

Мультиязычное приложение Здравствуй мир!

< resources > Важно отметить, что установка необходимой локализации в приложении происходит полностью автоматически и не требует дополнительных действий. Со стороны разработчика нужно только создать необходимые файлы и заполнить их соответствующими данными. Единственными недостатками стандартного механизма локализации Android является невозможность задать язык приложения независимо от системы в целом и необходимость хранить ресурсы в текстовых файлах в формате XML. Но, в большинстве случаев его возможностей всё же хватает для того чтобы удовлетворить потребности разра

Это руководство покажет вам, как преобразовать одноязычное приложение iOS, созданное с помощью Xcode, в многоязычное.

Загрузите свой файл ресурсов и получите итоговую стоимость прямо сейчас.

Файл ресурсов iOS:

Формат файла:
UTF-16 Unicode UTF-8 Unicode

С языка:

На язык:
— Китайский (упрощенный) Китайский (традиционный) Датский Голландский Английский Французский Немецкий Итальянский Японский Португальский Русский Испанский — Арабский Баскский Каталонский Чешский Финский Греческий Иврит Хинди Венгерский Латынь Македонский Норвежский Пенджаби Персидский Польский Португальский (Португалия) Румынский Шведский Тамильский Тайский Турецкий Украинский Вьетнамский

У вас уже есть переводчики?

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

Введение

Процесс локализации приложения для iOS включает в себя следующее:

1. Подготовка файлов ресурсов для локализации.
2. Сбор всех текстов, используемых в приложении, в файлы ресурсов.
3. Перевод файлов ресурсов.
4. Интеграция файлов ресурсов обратно в приложение.

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

Все приложения для iOS построены с использованием текстов Unicode, закодированных как UTF-16. Симуляторы iPhone и iPad поддерживают этот формат и позволяют предварительно просмотреть переведенное приложение.

1. Создание ресурсов, локализуемых в Xcode

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

2. Локализация файлов Interface Builder

Извлечение строк

Чтобы извлечь строки из файлов ресурсов Interface Builder, вам необходимо запустить инструмент, подобный ibtool , который входит в стандартную установку комплекта разработчика.

Чтобы извлечь файлы, откройте Терминал в каталоге проекта и выполните команду:
ibtool --generate-strings-file Example.strings en.lpoj/Example.xib
Это создаст файл Example.strings. Откройте его, и вы увидите множество парных значений объекта-строки.

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

Обработка дублированных строк

Файл ресурсов может содержать повторяющиеся строки, такие как некоторые названия для кнопок в разных состояниях.

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

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

Вы почти готовы к выпуску, только не забудьте его проверить.

Вот некоторые вещи, на которые стоит обратить внимание:

Просчет	Что может случиться	Как исправить
Переведенные строки выходят за границы	Немецкий, французский, испанский и другие европейские языки обычно составляют от 120% до 150% размера английского текста. Азиатские языки обычно составляют 50%-70%.	Рекомендуем адаптировать графический интерфейс к строкам разных размеров. Система локализации iOS ICanLocalize проверяет длину строк и предупреждает о слишком длинных или слишком коротких строках.
Отсутствующие символы форматирования	Многие строки содержат местозаполнители для данных, такие как %s для текста и %d для чисел. Другие строки включают HTML-код. Если перевод не включает такое же форматирование, приложение не будет работать.	Наша система перевода позволяет вам вводить «обязательные» последовательности. Это обеспечит, чтобы переводы включали те же последовательности, что и оригиналы. В противном случае вам следует вручную просмотреть все строки и убедиться, что символы форматирования совпадают.
Перевод вне контекста	Всегда есть вероятность, что переводчик не совсем понял значение строки. Это происходит, когда приложения содержат короткие и не описательные строки.	Перед началом работы отправьте полное описание приложения переводчику. После этого сделайте снимки экрана приложения и отправьте переводчику для окончательной проверки. Добавление комментариев к строкам поможет вам получить отличный перевод.

Устранение неполадок

Если строки Localizable.strings присутствуют в переведенном файле, но не локализуются на устройстве, проверьте кодировку символов файла.

В отличие от симулятора iPhone, реальное устройство распознает только строковые файлы в формате UTF-16. Всегда проверяйте локализации на устройстве, так как симулятор и устройство не всегда ведут себя одинаково.

Переведенные файлы ресурсов, загружаемые из ICanLocalize , имеют кодировку UTF-16. Они содержатся в архивах gzip , чтобы ваш браузер не изменял их при загрузке.

Обновление перевода, когда приложение для iOS развивается

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

Чтобы обновить переводы, снова запустите genstrings , для создания нового файла Localizable.strings. Затем перезапустите ibtool , чтобы сгенерировать новые строковые файлы.

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

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

Нужен перевод для вашего iOS-приложения?

ICanLocalize предлагает

«Мы используем ICanLocalize с 2012 года, и это действительно упростило наш рабочий процесс, когда речь заходит о переводе нашего контента для разных рынков. Больше не нужно искать переводчиков на разные языки, учить их пользоваться инструментами перевода, индивидуально составлять счета и т. д., поскольку ICanLocalize делает все это для нас! Мы используем сервисы ICanLocalize для перевода наших веб-сайтов, приложений, информационных бюллетеней и других маркетинговых материалов, и вы всегда можете рассчитывать на быструю работу. Я понимаю, что все это заявление звучит как платная реклама или что-то в этом роде, но я действительно не написал ничего, что не соответствует действительности или не является моим подлинным мнением! Я бы порекомендовал ICanLocalize в любое время!»

«ICanLocalize — это лучшее решение для быстрых и качественных переводов вашего приложения. Мы пользуемся их услугами для всех наших приложений с хорошими результатами и положительными отзывами наших пользователей. Я рекомендую использовать ICanLocalize для локализации ваших приложений.»

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

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

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

Локализация приложения

Ресурсы сборки также оказываются очень кстати когда требуется локализовать окно. Используя ресурсы, вы позволяете элементам управления изменяться в соответствии с текущими параметрами культуры в Windows, что особенно удобно в случае таких элементов управления, как текстовые метки и изображения, которые чаще всего требуется переводить на различные языки.

На некоторых платформах локализация осуществляется путем предоставления множества копий таких элементов пользовательского интерфейса, как таблицы строк и изображения. В WPF локализация не является столь же детальной. Здесь единицей локализации является XAML-файл (формально это скомпилированный BAML-pecypc, который встраивается в приложение). При желании поддерживать три различных языка, потребуется включить три BAML-pecypca. WPF будет выбирать из них подходящий на основании текущих настроек культуры на компьютере, на котором выполняется приложение. (Точнее - WPF будет использовать для принятия решения значение свойства CurrentUICulture в обслуживающем пользовательский интерфейс потоке.)

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

При создании локализованного WPF-приложения каждый локализованный BAML-pecypc помещается в отдельную подчиненную сборку. Для того чтобы приложение могло использовать эту сборку, она размещается в подпапке под основной папкой приложения вроде подпапки fr-FR, предназначенной для французского языка. После этого приложение может связываться с этой подчиненной сборкой автоматически путем использования технологии зондирования (probing) , которая является частью.NET Framework, начиная с версии 1.0.

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

Создание локализуемых пользовательских интерфейсов

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

Не применяйте жестко закодированные значения ширины или высоты (или, по крайней мере, не используйте их с элементами, которые содержат непрокручиваемое текстовое содержимое).

Устанавливайте для свойства Window.SizeToContent значение Width, Height или WidthAndHeight, так чтобы размер окна мог увеличиваться по мере необходимости. (Опять-таки, это является обязательным не всегда; все зависит от структуры окна, но в некоторых случаях это очень полезно.)

Используйте для просмотра текста большого объема элемент ScrollViewer .

При желании локализовать приложение на язык, имеющий значительно отличающийся набор символов, понадобится использовать другой шрифт. Сделать это можно путем локализации в пользовательском интерфейсе свойства FontFamily или применения сложного шрифта вроде Global User Interface, Global Sans Serif или Global Serif, каждый из которых поддерживает все языки.

Может также потребоваться обдумать, каким образом компоновка будет работать при раскладке "справа налево" (вместо стандартной английской раскладки "слева направо"). Например, в арабском и иврите используется раскладка "справа налево". Этим поведением можно управлять посредством установки на каждой странице или в каждом окне приложения свойства FlowDirection. Более подробную информацию о раскладках "справа налево" можно найти в справке Visual Studio, в разделе Bidirectional Features (Средства двунаправленности).

Локализация - сложная тема. WPF предлагает работоспособное, но еще недостаточно зрелое решение. После того, как вы познакомитесь с основами, стоит заглянуть в документ Microsoft, посвященный локализации WPF, который доступен по адресу http://wpflocalization.codeplex.com вместе с кодом примеров. Можно ожидать, что в будущем поддержку локализации будет улучшена в инструментах проектирования, таких как Visual Studio и Expression Blend.

Подготовка приложения для локализации

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

en-US

Это укажет компилятору, что языком (культурой) по умолчанию для приложения должен быть английский (США) (очевидно, что при необходимости можно выбрать другой язык). После внесения этой корректировки процесс компоновки изменится. При следующей компиляции приложения будет создана подпапка по имени en-US. Внутри этой папки будет находиться подчиненная сборка с таким же именем, как и у приложения, и расширением.resources.dll (например, LocalizableApplication.resources.dll).

В этой сборке будут содержаться все скомпилированные BAML-ресурсы для приложения, которые раньше хранились в основной сборке приложения.

Формально приложение локализуется не для какого-то конкретного языка, а для культуры, в которой учитываются региональные отличия. Культуры обозначаются с помощью двух разделенных дефисом идентификаторов. Первый указывает язык, а второй - страну. Следовательно, fr-CA означает французский язык, на котором разговаривают в Канаде, a fr-FR - французский, на котором общаются во Франции. Полный список имен культур и их идентификаторов можно найти в справке Visual Studio, в разделе, посвященном классу System.Globalization.Culturelnfo .

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

Теперь при запуске данного приложения среда CLR будет автоматически искать подчиненные сборки в соответствующем каталоге на основании региональных параметров компьютера, и загружать подходящий локализованный ресурс. Например, при запуске приложения на компьютере с культурой fr-FR среда CLR будет искать подпапку fr-FR и использовать подчиненные сборки, которые обнаружит там. Это означает, что для добавления в локализованное приложение поддержки дополнительных культур, потребуется просто добавить соответствующие дополнительные подпапки и подчиненные сборки, не беспокоясь об исходном исполняемом файле приложения.

Когда среда CLR начинает зондировать папки на предмет наличия подчиненной сборки, она следует нескольким простым правилам очередности:

Сначала она проверяет самый специфический из всех доступных каталог. Это означает, что CLR ищет подчиненную сборку, предназначенную для текущего языка и региона (вроде fr-FR).

Если CLR не удается обнаружить такой каталог, она начинает искать подчиненную сборку, предназначенную для текущего языка (такого как fr).

Если ей не удается найти и такой каталог, тогда генерируется исключение IOException.

Зачастую локализация приложений - пустая трата денег. Многие понимают под этим 20-долларовый перевод интерфейса, тогда как настоящая локализация - это адаптация приложения под менталитет и особенности жителей той или иной страны. А это стоит намного дороже.

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

Неправильный путь

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

Правильный путь

Перед подготовкой к локализации необходимо сделать следующие шаги:

1. подробно описать приложение, его функции и особенности,
2. подготовить скриншоты приложения,
3. подготовить для переводчика файл.ipa (как вариант, есть и другие способы), чтобы он мог протестировать приложение,
4. подготовить файл localizable.strings.

Вот этот «пакет документов» уже можно высылать переводчику.

А теперь самый главный совет.

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

Никаких бюро переводов, никаких переводчиков-нерезидентов. Найти правильных переводчиков можно на таких сайтах, как oDesk или Elance.

Критика приветствуется. Пишите в комментариях. И не забывайте лайкать!

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

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

Все переводы выполняются профессиональными переводчиками-носителями языка. Мы переводим на 68 языков , а также на другие языковые пары.

Локализация десктопных, браузерных и мобильных игр

Мы работаем с издателями и разработчиками мобильных и игровых проектов, помогая делать доступными приложения под iOS, Android, HTML5 на более, чем 60 языках. Помимо перевода строковых ресурсов самих приложений, мы также пишем и переводим описания для App Store и Google Play.

Лингвистическое тестирование

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

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

Расчет стоимости

Стоимость локализации и перевода рассчитывается исходя из объема текста (количества знаков с пробелами). Ознакомьтесь с расценками на перевод . При подсчете не учитываются теги, ключи, разметка.