Разработка приложений с поддержкой двунаправленного текста

Спроектируйте своё приложение, чтобы обеспечить поддержку двунаправленного текста (BiDi), позволяющую комбинировать системы письма справа налево (RTL) и слева направо (LTR), которые обычно содержат разные типы алфавитов.

Системы написания справа налево, такие как те, которые используются на Ближнем Востоке, Центральной и Южной Азии, а также в Африке, имеют уникальные требования к проектированию. Для этих систем записи требуется двунаправленная поддержка текста (BiDi). Поддержка BiDi — это возможность ввода и отображения текста в порядке справа налево (RTL) или слева направо (LTR).

В Windows включены в общей сложности девять языков BiDi.

• Два полностью локализованных языка. Арабский и иврит.
• Семь пакетов языкового интерфейса для развивающихся рынков. Персидский, Урду, Дари, Центральный курдский, Синдхи, Пенджаби (Пакистан) и Уйгур.

Этот раздел содержит философию проектирования Windows BiDi и примеры, которые показывают рекомендации по проектированию BiDi.

Элементы дизайна Bidi

Четыре элемента влияют на решения по проектированию BiDi в Windows.

• Зеркальное отображение пользовательского интерфейса. Потоки интерфейса пользователя позволяют отображать содержимое справа налево в своем родном формате. Дизайн пользовательского интерфейса чувствует себя локально на рынках BiDi.
• Согласованность в пользовательском интерфейсе. Дизайн выглядит естественно при ориентации с правого на левый. Элементы пользовательского интерфейса имеют единое направление макета и отображаются так, как ожидает пользователь.
• Оптимизация сенсорного ввода. Как и сенсорный пользовательский интерфейс в не ориентированном на зеркало пользовательском интерфейсе, элементы легко доступны, и они естественны для сенсорного взаимодействия.
• Поддержка смешанного текста. Поддержка направления текста обеспечивает великолепное отображение смешанного текста (английский текст на сборках BiDi, и наоборот).

Общие сведения о проектировании компонентов

Windows поддерживает четыре элемента конструктора BiDi. Давайте рассмотрим некоторые основные важные функции Windows (предыдущие версии) и предоставьте некоторый контекст о том, как они влияют на ваше приложение.

Следуйте в том направлении, которое кажется вам естественным.

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

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

Плитка BiDi

Английская плитка

Получайте уведомления плиток, которые корректно читаются

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

Согласованный, простой и удобный пользовательский интерфейс RTL

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

Ввод текста в любом направлении

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

Использование любого приложения на любом языке

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

Правильно отображать скобки

При внедрении алгоритма BiDi Parenthesis Algorithm (BPA) парные скобки всегда отображаются правильно, независимо от языковых свойств или выравнивания текста.

Неправильные скобки

Правильные скобки

Typography

Windows использует шрифт пользовательского интерфейса Segoe для всех языков BiDi. Этот шрифт формируется и масштабируется для пользовательского интерфейса Windows.

Пример #1: музыкальное приложение BiDi

Обзор

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

Установка направления пользовательского интерфейса

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

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

Обработка текста

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

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

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

Например, без пользовательской обработки макета строки имя исполнителя "The Contoso Band." будет отображаться как ".The Contoso Band".

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

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

string NormalizeTextDirection(string data) 
{
    if (data.Length > 0) {
        var lastCharacterDirection = DetectCharacterDirection(data[data.Length - 1]);

        // If the last character has strong directionality (direction is not null), then the text direction for the string is already consistent.
        if (!lastCharacterDirection) {
            // If the last character has no directionality (neutral character, direction is null), then we may need to add a direction marker to
            // ensure that the last character doesn't inherit directionality from the outside context.
            var appTextDirection = GetAppTextDirection(); // checks the <html> element's "dir" attribute.
            var dataTextDirection = DetectStringDirection(data); // Run through the string until a non-neutral character is encountered,
                                                                 // which determines the text direction.

            if (appTextDirection != dataTextDirection) {
                // Add a direction marker only if the data text runs opposite to the directionality of the app as a whole,
                // which would cause the neutral characters at the ends to flip.
                var directionMarkerCharacter =
                    dataTextDirection == TextDirections.RightToLeft ?
                        UnicodeDirectionMarkers.RightToLeftDirectionMarker : // "\u200F"
                        UnicodeDirectionMarkers.LeftToRightDirectionMarker; // "\u200E"

                data += directionMarkerCharacter;

                // Prepend the direction marker if the data text begins with a neutral character.
                var firstCharacterDirection = DetectCharacterDirection(data[0]);
                if (!firstCharacterDirection) {
                    data = directionMarkerCharacter + data;
                }
            }
        }
    }

    return data;
}

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

Пример 2. Почтовое приложение BiDi

Обзор

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

Установка направления пользовательского интерфейса

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

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

Обработка текста

Пользовательский интерфейс

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

Редактирование текста

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

Связанные темы

• Настройка макета и шрифтов и поддержка RTL
• Глобализация и локализация