Это руководство покажет вам, как преобразовать одноязычное приложение iOS, созданное с помощью Xcode, в многоязычное.
Загрузите свой файл ресурсов и получите итоговую стоимость прямо сейчас.
Файл ресурсов iOS:
Формат файла:
UTF-16 Unicode UTF-8 Unicode
С языка:
На язык:
— Китайский (упрощенный) Китайский (традиционный) Датский Голландский Английский Французский Немецкий Итальянский Японский Португальский Русский Испанский — Арабский Баскский Каталонский Чешский Финский Греческий Иврит Хинди Венгерский Латынь Македонский Норвежский Пенджаби Персидский Польский Португальский (Португалия) Румынский Шведский Тамильский Тайский Турецкий Украинский Вьетнамский
У вас уже есть переводчики?
Предлагаем бесплатно воспользоваться нашей системой перевода и сократить время, необходимое для управления и координации работы по переводу вашего приложения.
Введение
Процесс локализации приложения для iOS включает в себя следующее:
- Подготовка файлов ресурсов для локализации.
- Сбор всех текстов, используемых в приложении, в файлы ресурсов.
- Перевод файлов ресурсов.
- Интеграция файлов ресурсов обратно в приложение.
Поскольку приложения для 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 непосредственно в сайт, поэтому, когда переводы готовы, я могу просто заменить мои строковые файлы в моем проекте, и все сделано.»
Если вы желаете перевести и повторно опубликовать это руководство, пожалуйста сначала Скажите нам, где вы хотите опубликовать его и несколько слов о себе.
Мы переводим на иностранные языки компьютерные программы, игры и онлайн-приложения.
Помимо строковых ресурсов интерфейса, мы выполним перевод справочной системы, маркетинговых текстов, веб-сайта. При необходимости качественно переозвучим или переснимем видео-ролик, перерисуем графику, перепишем тексты на нужном языке.
Все переводы выполняются профессиональными переводчиками-носителями языка. Мы переводим на 68 языков , а также на другие языковые пары.
Локализация десктопных, браузерных и мобильных игр
Мы работаем с издателями и разработчиками мобильных и игровых проектов, помогая делать доступными приложения под iOS, Android, HTML5 на более, чем 60 языках. Помимо перевода строковых ресурсов самих приложений, мы также пишем и переводим описания для App Store и Google Play.
Лингвистическое тестирование
После того как собрана локализованная версия приложения, необходимо, чтобы переводчик-локализатор его протестировал на национальной версии ОС. Во время такого лингвистического тестирования, локализатор сделает скриншоты проблемных мест (не переведенные, слишком длинные строчки, неверная кодировка или направление текста, неверный контекст) и вместе с разработчиком внесет необходимые изменения в ресурсные файлы.
Если вы перевели приложение самостоятельно или силами стороннего подрядчика, у нас можно заказать лингвистическое тестирование локализации.
Расчет стоимости
Стоимость локализации и перевода рассчитывается исходя из объема текста (количества знаков с пробелами). Ознакомьтесь с расценками на перевод . При подсчете не учитываются теги, ключи, разметка.
Локализация приложения
Ресурсы сборки также оказываются очень кстати когда требуется локализовать окно. Используя ресурсы, вы позволяете элементам управления изменяться в соответствии с текущими параметрами культуры в 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.
Процесс локализации часто означает больше, чем просто языковые настройки вашего приложения для различных регионов. Сюда также относятся и правильные для разных регионов время, дата, формат их отображения. Если вы рассчитываете, что ваше приложение имеет шансы пойти в широкую международную аудиторию, вам сразу необходимо думать о грамотной локализации приложения, чтобы потом не копаться в коде всей программы и не тратить уйму времени на настраивание ее для разных регионов планеты.
С использованием 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 :
< 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 ресурсы будут следующими:
< resources> < string name= "app_name" > My Application < string name= "hello_world" > Hello world! < / string> < string name= "action_settings" > Settings < string name= "word" > Word < / 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);
