Локализация

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

Если вы хотите сразу перейти к техническим сведениям о локализации приложений Xamarin, начните с одной из этих статей, относящихся к конкретной платформе:

  • Кроссплатформенная локализация Xamarin.Forms с помощью RESX-файлов.
  • Локализация собственной платформы Xamarin.iOS.
  • Локализация собственной платформы Xamarin.Android.

i18n и L10n

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

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

Интернационализация часто сокращается до i18n - сокращено для 18 букв между "i" и "n". Локализация также сокращена до L10n — для 10 букв между "L" и "n".

Общие сведения

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

  • Макеты экрана и текст,
  • Значки, графика и цвета,
  • Видео и звуковые файлы,
  • Динамическое форматирование текста и текста (например, числа, валюта и даты),
  • Изменения макета для языков справа налево (RTL) и
  • Сортировка данных.

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

Вопросы проектирования

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

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

Макеты и длина строки

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

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

Сравните длину строк для нескольких элементов на начальном экране iOS на английском, немецком и японском языках:

German vs Japanese string length

Обратите внимание, что Параметры на английском языке (8 символов) требует 13 символов для перевода на немецкий язык, но только 2 символа на японском языке.

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

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

Проверка ввода

Остерегайтесь допущений при написании правил проверки. Может показаться допустимым требовать ввода текстового поля как минимум три символа на английском языке, так как одна буква очень редко имеет какое-либо значение. Однако на китайском и японском языках один символ может быть допустимым вводом, а для этих языков не имеет смысла сообщение проверки "по крайней мере 3 символа".

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

Напишите правила проверки с учетом интернационализации — выберите наименее строгие правила или напишите логику, чтобы она работала по-разному для каждого языка.

Изображения и цвет

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

  • Изображения с изображением людей или определенных расположений — ваше приложение может оказаться более релевантными для пользователей, если оно отображает локальных пользователей или расположений.
  • Значки . Некоторые значки могут быть характерными для языка и региональных параметров, и вы можете упростить использование приложения, локализуя изображения для отражения локального понимания.
  • Цвета — некоторые культуры понимают цвета по-разному — красный может означать предупреждение в одном регионе, но удачи в другом. Обратитесь к собственным докладчикам при разработке приложения, чтобы определить, следует ли создавать механизм локализации цветов.

Видео и звук

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

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

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

Даты, время, числа и валюта

Если вы используете функции форматирования .NET, не забудьте указать язык и региональные параметры, чтобы десятичные разделители правильно анализировались (и не создавайте исключения преобразования). Например, 1,99 и 1,99 являются допустимыми десятичными представлениями в зависимости от языкового стандарта.

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

double.Parse("1,999.99", CultureInfo.InvariantCulture);

Если пользователь приложения вводит данные, выполните его синтаксический анализ с помощью экземпляра CultureInfo, который отражает языковой стандарт:

double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));

Дополнительные сведения см. в статьях MSDN по синтаксическому анализу числовых строки синтаксическому анализу строк даты и времени .

Языки справа налево (RTL)

Некоторые языки, такие как арабский, иврит и Урду (например, справа налево). Приложения, поддерживающие эти языки, должны использовать макеты экрана, которые адаптируются для чтения справа налево, например:

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

Как iOS, так и Android поддерживают макеты справа налево и отрисовку шрифтов со встроенными функциями, которые помогают внести указанные выше корректировки. В настоящее время Xamarin.Forms не поддерживает отрисовку RTL автоматически.

Сортировка

Разные языки определяют порядок сортировки алфавитов по-разному, даже если они используют один и тот же набор символов.

Сведения о сравнении строк см. в рекомендациях по использованию строк в платформа .NET Framework, например, если язык (CultureInfo) влияет на порядок сортировки.

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

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

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

Данные из внешних источников

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

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

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

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

Не переведите

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

  • URL-адреса — если вы перечисляете URL-адрес, его может потребоваться изменить по языку. Например, facebook.com не требует перевода, он автоматически обнаруживает язык на основном сайте. Другие сайты содержат содержимое, зависяющее от языкового стандарта, и вам может потребоваться предложить другой URL-адрес, например yahoo.com или yahoo.fr или yahoo.it.
  • Телефонные номера , особенно с различными кодами страны или номерами для абонентов, которые говорят на определенном языке.
  • Контактные данные — адреса и другие сведения могут отличаться в зависимости от языка или языкового стандарта.
  • Названия продуктов товарных & знаков — некоторые строки не требуют перевода, так как они всегда написаны на одном языке.

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

Форматированный текст

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

Советы перевода

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

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

Локализация полных строк, а не слов

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

Плохо:

"You have"
"no"
"message"
"messages"

а затем попытайтесь создать правильную фразу во всплывающем коде с помощью объединения строк:

Плохо:

"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"

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

Разрешить повторное упорядочение параметров

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

Хорошо:

"a {0} b {1} cde {3}"

может быть переведено следующее (при изменении положения и порядка заполнителей)

"{2} {3} f g h {0}"

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

Использование нескольких строк для кратности

Избегайте таких строк, как "You have {0} message/s." использование определенных строк для каждого состояния, чтобы обеспечить лучшее взаимодействие с пользователем:

Хорошо:

"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."

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

Разрешение пола

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

Существует также более очевидное дело даже на английском языке, где строки ссылаются на конкретного человека или пользователя вашего приложения. Например, на некоторых сайтах отображаются такие сообщения, как "Bob commented on his post" строки для мужчин, женщин и не двоичного или неизвестного пола:

Хорошо:

"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"

Не используйте строки повторно

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

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

  • "Вкл." — отображается на самом коммутаторе
  • "Выкл." — отображается на самом переключателе
  • "Вкл." — отображается в метке
  • "Выкл." — отображается в метке

Это обеспечивает максимальную гибкость для переводчика:

  • В целях разработки, возможно, сам переключатель использует строчные буквы "вкл." и "выкл.", но метка отображения использует верхний регистр "Вкл. " и "Выкл.".
  • Для некоторых языков может потребоваться сокращенное значение переключателя, которое должно соответствовать элементу управления пользовательского интерфейса, а полное (переведенное) слово может отображаться в метке.
  • Кроме того, для некоторых языков для отрисовки переключателя можно использовать "I" и "O" для культурного знакомства, но может потребоваться, чтобы метка читала "Вкл. " или "Выкл.".

Службы перевода

Машинный перевод

Чтобы создать функции перевода в приложение, рассмотрите API Переводчик текста Azure.

В целях тестирования можно использовать один из многих средств онлайн-перевода для включения локализованного текста в приложение во время разработки:

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

перевод Professional

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

Одним из самых известных служб является LionBridge. Большинство профессиональных служб поддерживают все распространенные типы файлов, включая строки, XML, RESX и POT/PO.

Сводка

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

Эти понятия можно применять к различным методам кроссплатформенной и кроссплатформенной интернационализации, которые можно использовать с помощью Xamarin.

Продолжайте читать технические сведения о интересующей вас платформе:

  • Кроссплатформенная локализация Xamarin.Forms с помощью RESX-файлов.
  • Локализация собственной платформы Xamarin.iOS.
  • Локализация собственной платформы Xamarin.Android.