Когда направление текста становится риском

Когда речь заходит о поддержке иврита в медицинском ПО, разговор обычно сводится к одному вопросу: переведён ли интерфейс. Это наименее важный вопрос. Система может быть прекрасно переведена и всё равно показывать врачу неверное число — потому что проблема не в переводе слов, а в порядке, в котором браузер рисует числа внутри фразы на иврите.

Что происходит на самом деле

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

Результат не теоретический. Вот три примера, найденных при системной проверке экранов на иврите:

Реальные данные	Что нарисовано на экране	Что доходит до врача
Артериальное давление 140.4 / 87.6	87.6 / 140.4, а единица измерения перед числом	Систолическое и диастолическое поменялись местами: гипертония читается как гипотония
Референсный диапазон в лаборатории: больше 60	Знак нарисован как «меньше»	Значение в норме читается как отклонение, а отклонение — как норма
Кредит на 25 шекелей со знаком минус	Знак перескакивает на другую сторону суммы	Кредит в карточке счёта читается как дебет

Случай со знаками сравнения особенно опасен

В первых двух примерах механизм разный. В артериальном давлении сами символы не изменились, они лишь были переупорядочены. В референсном диапазоне происходит другое: символы «больше» и «меньше» определены в Unicode как символы с зеркальным начертанием. Когда они находятся на нечётном уровне вложенности, то есть в контексте «справа налево», движок рисует зеркальный символ. Ничто не сдвигается. Сам символ заменяется своей противоположностью.

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

Почему скриншоты этого не ловят

Это самый важный момент для управляющего клиникой, оценивающего систему. Обычная проверка поддержки иврита — открыть экраны и посмотреть. Но перевёрнутый диапазон по-прежнему выглядит как диапазон. Два поменявшихся местами числа по-прежнему выглядят как нормальное давление. Глаз видит правильную структуру и идёт дальше. Только проверка, сравнивающая фактический порядок символов с исходными данными, выявляет расхождение.

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

• Составной витальный показатель, например артериальное давление или оценка боли по шкале.
• Результат лабораторного анализа с референсным диапазоном и знаком сравнения.
• Строка кредита в карточке счёта, то есть отрицательная сумма.
• Диапазон времени приёма, например время начала и время окончания.
• Назначение дозировки, включающее число, единицу и частоту в одной строке.

Почему это происходит почти в любой переведённой системе

Потому что поддержка обратного направления обычно строится задним числом, как слой заплаток поверх оформления, созданного под английский. В известной зрелой системе с открытым кодом в этой сфере измерение таблицы стилей показывает, что лишь около 5% правил оформления меняются между обычным режимом и режимом «справа налево», а интерфейс на иврите переведён примерно на 61% по подсчёту строк. Такие числа порождают гибридные экраны: часть выровнена правильно, часть нет, а кнопки остались не на своих местах.

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

Практическое правило: единица изоляции — это данные в том виде, в каком их читает врач, а не отдельное число. Артериальное давление — это одни данные. Диапазон дат — одни данные. Сумма со знаком — одни данные. Изоляция каждого числа по отдельности, когда разделитель остаётся открытым, точно воспроизводит неисправность.

Как решить это правильно

Решение — не список исправлений для экранов, а три инфраструктурных решения:

1. Типизированный слой форматирования. Каждое числовое значение проходит через функцию, которая знает его тип — показатель, сумма, диапазон, идентификатор, дата — и возвращает одну изолированную последовательность. Разработчик, пишущий экран, этого не решает.
2. Одна таблица стилей с логическими свойствами. Вместо физических «лево» и «право» используются «начало» и «конец». Так нет двух таблиц, которые нужно поддерживать, и новый экран рождается правильным в обоих направлениях.
3. Тесты порядка символов в непрерывной интеграции. Не скриншоты, а проверки, подтверждающие, что отображаемое значение совпадает по порядку с сохранённым. Такой тест падает в момент, когда кто-то добавляет экран, не прошедший через слой форматирования.

Что спросить у поставщика

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

Поставщик, у которого есть ясные ответы на эти три вопроса, вероятно, отнёсся к теме серьёзно. Поставщик, который отвечает, что система переведена на иврит, ответил на другой вопрос.

Назад в блог