Одной из задач в рамках проекта «Доминикана» является обеспечение многоязычности системы в самом широком понимании этого слова. Хочу выделить и обсудить с сообществом некоторые аспекты, связанные с этой темой.
В первую очередь под мультиязычностью конфигурации понимают поддержку разных языков интерфейсов, сообщений и метаданных.
Инструмент, предоставляемый платформой для перевода конфигураций, достаточно гибок и универсален. Подробно он описан в публикации //infostart.ru/public/141022/
Здесь основные трудности скорее не технологического, а методологического плана – как понять контекст переводимой фразы, как организовать работу переводчика, как обеспечить корректный и единообразный перевод специальной терминологии и т.д.
Эти вопросы пытается решать конфигурация 1C-Translation, бесплатно поставляемая фирмой 1С (http://1c-dn.com/downloads/1c_translator/)
Куда более интересно обсудить задачу обеспечения поддержки нескольких языков данных. Она может возникнуть при работе интернациональной компании в единой базе.
Формализуем задачу: необходимо обеспечить представление на разных языках строковых реквизитов ссылочных объектов. Нужно предусмотреть корректную работу механизма при отображении данных на форме, представлении ссылок, а также при вводе данных по строке (включая потенциальную возможность переопределения набора реквизитов, по которым осуществляется ввод и разные способы поиска по строке – по началу или любой части)
Можно выделить следующие критерии работы механизма:
- Производительность – при работе в многоязычном режиме не должна падать скорость работы с базой, в том числе на больших объемах данных.
- Гибкость – возможность подключения к механизму любых реквизитов объекта и языков данных.
- Простота поддержки – обеспечение работы механизма не должно замедлять разработку и поддержку системы.
- Опциональность – возможность отключения поддержки механизма для всей системы или её части.
Очевидно, что соблюсти все эти требования одинаково полно невозможно, поэтому надо искать разумный компромисс. Так, например, гибкость и простоту поддержки обеспечивает реализация механизма с помощью регистров сведений, но это на корню убивает производительность системы, или, наоборот, создание доп. реквизитов объекта метаданных для каждого языка данных обеспечивает хорошую производительность, но плохую гибкость.
Ниже приведу один из возможных способов такого компромисса, с уточнениями по каждому из этих пунктов (к публикации прикреплена база с конфигурацией, в которой можно посмотреть описываемую реализацию)
1) Производительность – для обеспечения этого показателя, для каждого объекта метаданных, который поддерживает многоязычность, добавлен дополнительный строковый реквизит, в котором хранится сериализованная структура представления разных реквизитов на разных языках. В обработке получения полей представления менеджера объекта, данный реквизит добавляется в список полей представления.
Представление реквизита на языке, который является основным в базе хранится непосредственно в самом реквизите. Если в представление входят многоязычные реквизиты и текущий язык данных не является основным для базы, то данные по берутся из десериализованной структуры представления многоязычных реквизитов.
Для обеспечения производительности подбора элемента на разных языках (а также для взаимодействия с разноязычными представлениями в запросах) в объект метаданных добавлена специальная табличная часть с индексацией по реквизиту «Представление».
2) Гибкость – набор языков данных хранится в справочнике, набор представлений на разных языках сохраняется перед записью объекта в специальные табличную часть и реквизит. Дополнительные реквизиты формы, визульно отображающие многоязычные строковые реквизиты на текущем языке, создаются интерактивно на форме при разработке объекта, по определённым правилам (отказ от программного добавления позволяет кастомизировать визуальное представление многоязычных реквизитов под каждый объект). Для удобного доступа к реквизитам на разных языках в отчётах в пользовательском режиме подключён механизм характеристик (видами характеристик являются пары «Язык» + «Имя реквизита», объединённые в единый ссылочный ключ, а значением – представление). Ограничение текущей реализации – набор строковых реквизитов для которых требуется поддержка многоязычности закладывается при разработке объекта метаданных и жёстко зашит в коде.
3) Простота поддержки – при разработке объекта метаданных с поддержкой многоязычности, определяется обязательный набор реквизитов и процедур, которые он должен содержать, вся логика процедур, обеспечивающая механизм, выносится в универсальные общие функции, в модулях объекта происходит только их вызов с нужными параметрами. Спец. реквизиты формы, необходимые для поддержки механизма, добавляются при создании формы программно, если не требуется их визуального отображения на форме (см. пункт 2).
4) Опциональность механизма – в системе создана функциональная опция «Поддерживать многоязычность данных», если она выключена, то обращение к процедурам механизма многоязычности не происходит, все события отрабатывают стандартным образом, данные по представлению берутся непосредственно из реквизитов.
Мультиязычность данных можно рассмотреть и под другим углом: система должна говорить с пользователем не только на одном языке, но и понятными ему терминами. Отсюда вытекает новая задача - заложить в систему механизмы обеспечивающие поддержку профессионального сленга данных.
Поясню, что имеется в виду на примере:
Есть некий мастер цеха, который ждёт поступления особого металла пригодного для изготовления обечайки. В спецификации на изготовление обечайки и прайсах поставщиков данный металл проходит под названием «Металл М1287». Для ответственного по закупкам этот металл должен оставаться металлом М1287, а для мастера цеха – «металлом для обечайки».
С технической точки зрения механизм поддержки сленга, включает в себя все требования, предъявляемые к механизму многоязычности данных и может быть построен на его основе (включая способы хранения и получения представления)
Различия этих двух механизмов проявляются в 2х моментах:
- При работе со сленгом добавляется новый разрез – контекст, в котором получается представление объекта (должность пользователя, функциональная область системы, в которой он в текущей момент работает)
- Различается способ ввода данных:
для многоязычности - ввод данных осуществляется на текущем языке пользователя, поддержка перевода элементов на другие языки базы – отдельная регламентная функция специального отдела;
для сленга – ввод разных представлений осуществляется через словарь, который может формироваться в том числе и программно (например, для металла М1287 – автоматически формируется запись в разрезе мастера цеха при составлении спецификации изготовления обечайки)
Выводы
Т.о. на многоязычность системы можно смотреть с разных точек зрения, в комментариях предлагаю обсудить бизнес потребности в таких механизмах и их техническую реализацию.
