Большинство мобильных приложений так или иначе разрабатывается для использования более чем в одной стране или одном регионе. Как следствие, перед разработчиками встаёт вопрос о локализации строковых ресурсов для различных языков.
К счастью в 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 используемого по умолчанию и для английской американской локализации:
< resources > < string name = "app_name" > Multilanguage Application < / string > < string name = "hello_world" > Hello World ! < / string > < / resources > |
Скриншот приложения:
Содержимое файла strings.xml для русской локализации:
< resources > Важно отметить, что установка необходимой локализации в приложении происходит полностью автоматически и не требует дополнительных действий. Со стороны разработчика нужно только создать необходимые файлы и заполнить их соответствующими данными. Единственными недостатками стандартного механизма локализации Android является невозможность задать язык приложения независимо от системы в целом и необходимость хранить ресурсы в текстовых файлах в формате XML. Но, в большинстве случаев его возможностей всё же хватает для того чтобы удовлетворить потребности разра |
Мы переводим на иностранные языки компьютерные программы, игры и онлайн-приложения.
Помимо строковых ресурсов интерфейса, мы выполним перевод справочной системы, маркетинговых текстов, веб-сайта. При необходимости качественно переозвучим или переснимем видео-ролик, перерисуем графику, перепишем тексты на нужном языке.
Все переводы выполняются профессиональными переводчиками-носителями языка. Мы переводим на 68 языков , а также на другие языковые пары.
Локализация десктопных, браузерных и мобильных игр
Мы работаем с издателями и разработчиками мобильных и игровых проектов, помогая делать доступными приложения под iOS, Android, HTML5 на более, чем 60 языках. Помимо перевода строковых ресурсов самих приложений, мы также пишем и переводим описания для App Store и Google Play.
Лингвистическое тестирование
После того как собрана локализованная версия приложения, необходимо, чтобы переводчик-локализатор его протестировал на национальной версии ОС. Во время такого лингвистического тестирования, локализатор сделает скриншоты проблемных мест (не переведенные, слишком длинные строчки, неверная кодировка или направление текста, неверный контекст) и вместе с разработчиком внесет необходимые изменения в ресурсные файлы.
Если вы перевели приложение самостоятельно или силами стороннего подрядчика, у нас можно заказать лингвистическое тестирование локализации.
Расчет стоимости
Стоимость локализации и перевода рассчитывается исходя из объема текста (количества знаков с пробелами). Ознакомьтесь с расценками на перевод . При подсчете не учитываются теги, ключи, разметка.
Процесс локализации часто означает больше, чем просто языковые настройки вашего приложения для различных регионов. Сюда также относятся и правильные для разных регионов время, дата, формат их отображения. Если вы рассчитываете, что ваше приложение имеет шансы пойти в широкую международную аудиторию, вам сразу необходимо думать о грамотной локализации приложения, чтобы потом не копаться в коде всей программы и не тратить уйму времени на настраивание ее для разных регионов планеты.
С использованием Android SDK, язык используемых локализованных строковых ресурсов и формата/значения времени, а также даты автоматически будут подстраиваться под тот регион и языковую среду, в которой работает устройство. Язык определяется стандартом ISO 639-1, страна - ISO 3166-1. То есть, можно смело говорить, что Android совместим с большинством стран мира (ну может разве какие африканские племена не в счет:)) и языками.
Локализация языка
Стоит отметить, что единственный язык, который 100% будет представлен в любом Android устройстве - это американский английский, обозначаемый кодом en_US . Чтобы произвести языковую локализацию вашего приложения, нужно в его папку res/ вложить дополнительные ресурсы, которые вы посчитаете нужным добавить.
Чтобы добавить альтернативные языки вашему приложению нужно создать папки в корневой папке res/, присваивая им имена типа: res/values-<языковой код> или res/values-<языковой код>-r<код страны> . Стоит отметить, что если вы определили для некоторого региона языковые настройки, то они, при использовании в приложения в этом регионе, будут приоритетными, то есть будут по умолчанию более "важными" для приложения и будут применяться первостепенно. Выше их приоритета может быть только так называемый мобильный код страны MCC . Мобильный код страны (определяемый с помощью мобильного кода сети MNC из Sim карты) определяет преимущественные ресурсы для данной страны.
Итак, давайте научимся создавать языковую локализацию. Создайте новое приложение, либо же откройте не слишком сложное существующее у вас приложение. Мы ставим задачу локализовать наше приложение для русско язычных регионов и англоязычных. Для настройки русского языка мы просто используем существующую папку res/values/strings.xml и создадим так необходимые нам строковые ресурсы. Для английского же языка, создаем подпапку /values-en в папке res/ ресурсов, и создаем следующий файл с адесом: res/values-en/strings.xml . В этот созданный нами файл мы и добавим английские строковые ресурсы. Как должен выглядеть код:
Для файла с русскими языковыми ресурсами res/values/strings.xml :
xml version= "1.0" encoding= "utf-8" ? > < resources> < string name= "app_name" > Мое приложение< / string> < string name= "hello_world" > Привет мир! < / string> < string name= "action_settings" > Настройки< / string> < string name= "word" > Слово< / string> < / resources>Для файла английской локализации res/values-en/strings.xml ресурсы будут следующими:
xml version= "1.0" encoding= "utf-8" ? > < resources> < string name= "app_name" > My Application string> < string name= "hello_world" > Hello world! < / string> < string name= "action_settings" > Settings string> < string name= "word" > Word string> < / resources>Все готово, теперь при запуске в англоязычной стране программа автоматически будет использовать ресурсы с папки res/values-en/strings.xml и отображать английский текст.
Стоит отметить, что для того, чтобы этот механизм языковой локализации корректно сработал в ваших приложениях, нужно для элементов программы, использующих текст, например при настройке android:text=""
для объектов
Если вы хотите выполнить локализацию строк в самом коде программы, если это не было сделано в файле layout.xml или других подобные ему файлах разметки интерфейса, то для локализации таких строк нужно вызвать в коде объект android.content.res.Resourses , который содержит все ресурсы в пакете приложения, и обратиться к необходимому ресурсу отсюда с помощью метода get.String . Вот как можно локализовать наш "Hellow world!" этим способом:
// Подключаем необходимый ресурс: android.content.res. Resources res = context. getResources(); String helloWorld = res. getString(R . string. hello_world); //Привязываем локализованную строку к элементуЕсть еще один способ произвести локализацию строковых ресурсов вашего приложения. Он довольно простой, проще всего, о чем здесь говорилось и будет говориться, но точно так же работающий. Итак, когда вы работаете над своим приложением в файлах разметки, типа activity_main.xml , то можно прямо здесь, без редактирования файлов ресурсов, настроить языковую локализация. Неважно, в каком режиме вы находитесь, Text или Design, находим на панели следующую кнопочку:
Жмем ее, выбираем первый пункт - Add Translation , и перед нами появляется окошко, где предлагается выбрать нужный для локализации язык. Находим с списке нужный язык, жмем на него и видим новое окно:
Как видите, в появившейся таблице 3 столбца: Key , Defuolt , Russian (ru) (потому, что я выбрал для локализации русский язык). В первом отображаются имеющиеся у нас строковые ресурсы в файле res/values/strings.xml , во втором - их значение в этом же файле res/values/strings.xml , ну а 3-е окно позволят нам здесь же ввести перевод всех существующий строковых ресурсов. Вводим нужный перевод, жмем ОК. Видим, что открылся файл ru\string.xml , а это значит, что программа сама создала необходимую папку для русскоязычной локализации. Все готово!
Локализация времени и даты
Во многих приложениях есть потребность работы с значением текущего времени и даты. Представьте себе огорчение ваших пользователей, которые изначально были так обрадованы присутствием языковой локализации, что уже были готовы купить полную версию программы, а тут на тебе - ваша программа поздравляет жителя Камчатки с новым годом на пол дня позднее, чем нужно было. Вот и все, прощай пользователь! Поэтому локализация времени и даты, как видите, тоже важное дело, и в Android SDK есть инструменты для настройки соответствия даты и времени с местом локализации устройства.
Локализация даты
Настройка локализации даты может быть выполнена с помощью класса DateFormat в пространстве имен android.text.format . Следующий фрагмент кода показывает, как получить строку с отформатированным под локализацию устройства значением даты:
// Получаем текущее время и дату: Date currentDate = Calendar . getInstance(). getTime(); // Получаем стандартный вид даты для текущей локализации устройства: java.text. DateFormat dateFormat; dateFormat = android.text.format. DateFormat . getDateFormat(this); // Форматируем текущую дату в соответствии с местоположением устройства: String formattedCurrentDate = dateFormat. format(currentDate);Если текущим местоположением устройства является, например, США, то формат даты по местному значению будет показан в виде 11/29/2014 . Классом DateFormat можно настроить и другие форматы даты. Если вместо команды getDateFormat исполнить, например, getLongDateFormat , то мы получим дату в таком виде: Понедельник, Декабрь 29, 2014 .
Локализация времени
С тех пор, как время представлено в Android SDK как Date объекты, оно также настраивается классом DateFormat в пространстве имен android.text.format . Тут все делается приблизительно также, как и с настройкой даты, с использованием того же метода. Смотрим код:
// Настраиваем текущие время и дату java.util. Date currentDate = Calendar . getInstance(). getTime(); // Настраиваем правильное отображение времени для текущей локализации устройства java.text. DateFormat timeFormat; timeFormat = android.text.format. DateFormat . getTimeFormat(this); // Настраиваем формат времени в соответствии с локализацией устройства String formattedTime = timeFormat. format(currentDate);Локализация приложения
Ресурсы сборки также оказываются очень кстати когда требуется локализовать окно. Используя ресурсы, вы позволяете элементам управления изменяться в соответствии с текущими параметрами культуры в 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. Внутри этой папки будет находиться подчиненная сборка с таким же именем, как и у приложения, и расширением.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.