Централизованное управление мультиязычными текстами в Dynamics 365: реальный кейс реализации
- Sarov+

- Jul 14
- 3 min read
При разработке корпоративных решений нередко возникает задача использования одного и того же текста в нескольких местах системы. На первый взгляд это кажется простой задачей, однако по мере развития проекта такой подход может привести к дублированию данных, ошибкам при обновлении информации и усложнению поддержки.
В этой статье мы поделимся реальным кейсом из нашей практики и покажем, как нам удалось централизовать управление мультиязычными текстами в Microsoft Dynamics 365 и Power Platform. Расскажем, с какой проблемой столкнулся клиент, какое архитектурное решение мы выбрали, какие технические сложности возникли во время реализации и каких результатов удалось достичь.
В одном из наших проектов клиент использовал юридические тексты одновременно на английском и арабском языках, причем они отображались сразу в нескольких компонентах системы. Мы разработали централизованное решение, которое позволило значительно упростить управление контентом, сократить количество ошибок и сделать дальнейшую поддержку системы гораздо удобнее.
А узнать больше можно в нашем видео:
Исходная проблема
В системе один и тот же текст использовался сразу в нескольких местах:
Canvas App;
Cloud Flow, генерирующем HTML-документы;
основной форме контакта в Dynamics 365.
Каждый раз при изменении текста пользователю приходилось вручную открывать каждое из этих мест и обновлять информацию отдельно.
Такой подход создавал сразу несколько проблем:
высокий риск человеческих ошибок;
вероятность появления разных версий одного и того же текста;
сложность сопровождения системы;
увеличение времени на внесение даже небольших изменений.
Чем больше становилось подобных текстов, тем менее управляемым становился весь процесс.
Выбранная архитектура
Вместо хранения текста непосредственно в различных компонентах системы мы решили создать единый источник данных (Source of Truth).
Для этого была создана отдельная таблица Dataverse, содержащая всю необходимую информацию для отображения текста независимо от того, где именно он используется.
Каждая запись содержала:
English Text;
Arabic Text;
Legal Text Type;
Display Language Mode.
Особенностью решения стало хранение текста непосредственно в HTML-формате. Благодаря этому удалось сохранить единое форматирование независимо от места отображения.
Поле Legal Text Type использовалось для определения типа текста, чтобы приложение автоматически выбирало нужную запись.
Поле Display Language Mode позволяло определить один из трех режимов отображения:
English Only;
Arabic Only;
Both Languages.
Кроме того, если для выбранного режима отсутствовал необходимый перевод, пользователь получал понятное сообщение об ошибке с рекомендацией обратиться к администратору системы.
Как работает решение
После внедрения новой архитектуры процесс обновления текста стал значительно проще.
Если необходимо изменить существующий текст, администратор открывает соответствующую запись таблицы и редактирует ее содержимое. Изменения автоматически используются во всех местах, где данный текст отображается.
Если требуется добавить новый тип текста, необходимо:
создать новую запись;
заполнить все необходимые поля;
добавить обращение к этой записи в тех компонентах системы, где новый текст будет использоваться.
Несмотря на небольшое дополнительное действие при создании новых записей, дальнейшая поддержка системы становится значительно проще.
Особенности работы с арабским языком
Одной из наиболее интересных технических задач стало корректное отображение арабского текста.
Поскольку арабский язык читается справа налево, обычная HTML-разметка приводила к некорректному отображению отдельных слов и предложений.
Для решения проблемы был использован атрибут:
dir="rtl"
Он обеспечивает правильное направление текста.
Дополнительно применялось выравнивание:
text-align: right;
Только сочетание этих двух решений позволило добиться корректного отображения текста во всех элементах интерфейса.
Передача стилей между различными компонентами
Изначально мы планировали хранить только "чистый" HTML без оформления.
Однако выяснилось, что один и тот же текст должен отображаться по-разному в разных местах системы.
Например:
на форме контакта использовался стандартный размер шрифта;
в документах, создаваемых Cloud Flow, текст должен был быть серым и меньшего размера.
Сначала была предпринята попытка использовать CSS-классы внутри HTML и описывать их уже в местах отображения.
На практике этот подход оказался неработоспособным.
Поэтому мы выбрали более простое решение — использование наследования CSS.
Контейнер, в котором отображался текст, получал необходимые стили, например:
color;
font-size.
Поскольку эти свойства наследуются дочерними элементами, весь HTML автоматически отображался в нужном формате без дополнительной обработки.
Возможные риски
Несмотря на простоту решения, у него есть определенные ограничения.
Поскольку текст хранится в HTML, администратору желательно иметь хотя бы базовое понимание HTML-разметки.
Даже случайное удаление одного символа может привести к некорректному отображению текста.
В нашем проекте это не стало проблемой, поскольку со стороны клиента был специалист, знакомый с HTML.
Тем не менее подобные риски необходимо заранее обсуждать при проектировании решения и учитывать при выборе архитектуры.
Заключение
Централизация хранения мультиязычных текстов позволила решить сразу несколько задач:
устранить дублирование данных;
сократить количество ошибок при обновлении информации;
значительно упростить сопровождение системы;
обеспечить единообразное отображение текста во всех компонентах Dynamics 365 и Power Platform.
Несмотря на необходимость хранения HTML-разметки, выбранный подход оказался наиболее эффективным для данного проекта. Вместо редактирования одинакового текста сразу в нескольких местах система получила единый источник данных, который значительно упростил дальнейшую поддержку и развитие решения.



Comments