Поделиться через

Локализация

  • Статья

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

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

i18n и L10n

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

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

Интернационализация часто сокращена до 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 и 199 являются допустимыми десятичными представлениями в зависимости от языкового стандарта.

Когда данные поступают из известного источника (т. е. из собственного кода или веб-службы), можно жестко закодировать идентификатор языка и региональных параметров, соответствующий форматированию, например 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-каналов до погоды, новостей или цен на акции. При отображении этого пользователю необходимо рассмотреть возможность отображения неуместных или непрочитанных сведений.

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

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

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

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

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

  • 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}"

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

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

Избегайте таких строк, как "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.

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

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

Профессиональный перевод

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

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

Итоги

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

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

Продолжайте чтение технических сведений для платформы, в которой вы хотите: