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

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

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

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

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

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

Элементы конструктора Bidi

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

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

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

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

Навигация в направлении, которое чувствует себя естественным

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

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

Плитка BiDi

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

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

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

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

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

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

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

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

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

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

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

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

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

Оформление текста

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

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

Обзор

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

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

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

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

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

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

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

	Английская строка (LTR)	Ивритская строка (RTL)
Выравнивание по левому краю	Hello, World!	בוקר טוב!
Выравнивание по правому краю	Hello, World!	!בוקר טוב

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

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

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

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

C#

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 по умолчанию зеркально. С точки зрения обработки текста почтовое приложение должно иметь более надежные возможности отображения текста и композиции для удовлетворения сценариев смешанного текста.

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

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

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

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

UI

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

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

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