Одной из задач в рамках проекта «Доминикана» является обеспечение многоязычности системы в самом широком понимании этого слова. Хочу выделить и обсудить с сообществом некоторые аспекты, связанные с этой темой.
В первую очередь под мультиязычностью конфигурации понимают поддержку разных языков интерфейсов, сообщений и метаданных.
Инструмент, предоставляемый платформой для перевода конфигураций, достаточно гибок и универсален. Подробно он описан в публикации //infostart.ru/public/141022/
Здесь основные трудности скорее не технологического, а методологического плана – как понять контекст переводимой фразы, как организовать работу переводчика, как обеспечить корректный и единообразный перевод специальной терминологии и т.д.
Эти вопросы пытается решать конфигурация 1C-Translation, бесплатно поставляемая фирмой 1С (http://1c-dn.com/downloads/1c_translator/)
Куда более интересно обсудить задачу обеспечения поддержки нескольких языков данных. Она может возникнуть при работе интернациональной компании в единой базе.
Формализуем задачу: необходимо обеспечить представление на разных языках строковых реквизитов ссылочных объектов. Нужно предусмотреть корректную работу механизма при отображении данных на форме, представлении ссылок, а также при вводе данных по строке (включая потенциальную возможность переопределения набора реквизитов, по которым осуществляется ввод и разные способы поиска по строке – по началу или любой части)
Можно выделить следующие критерии работы механизма:
- Производительность – при работе в многоязычном режиме не должна падать скорость работы с базой, в том числе на больших объемах данных.
- Гибкость – возможность подключения к механизму любых реквизитов объекта и языков данных.
- Простота поддержки – обеспечение работы механизма не должно замедлять разработку и поддержку системы.
- Опциональность – возможность отключения поддержки механизма для всей системы или её части.
Очевидно, что соблюсти все эти требования одинаково полно невозможно, поэтому надо искать разумный компромисс. Так, например, гибкость и простоту поддержки обеспечивает реализация механизма с помощью регистров сведений, но это на корню убивает производительность системы, или, наоборот, создание доп. реквизитов объекта метаданных для каждого языка данных обеспечивает хорошую производительность, но плохую гибкость.
Ниже приведу один из возможных способов такого компромисса, с уточнениями по каждому из этих пунктов (к публикации прикреплена база с конфигурацией, в которой можно посмотреть описываемую реализацию)
1) Производительность – для обеспечения этого показателя, для каждого объекта метаданных, который поддерживает многоязычность, добавлен дополнительный строковый реквизит, в котором хранится сериализованная структура представления разных реквизитов на разных языках. В обработке получения полей представления менеджера объекта, данный реквизит добавляется в список полей представления.
Представление реквизита на языке, который является основным в базе хранится непосредственно в самом реквизите. Если в представление входят многоязычные реквизиты и текущий язык данных не является основным для базы, то данные по берутся из десериализованной структуры представления многоязычных реквизитов.
Для обеспечения производительности подбора элемента на разных языках (а также для взаимодействия с разноязычными представлениями в запросах) в объект метаданных добавлена специальная табличная часть с индексацией по реквизиту «Представление».
2) Гибкость – набор языков данных хранится в справочнике, набор представлений на разных языках сохраняется перед записью объекта в специальные табличную часть и реквизит. Дополнительные реквизиты формы, визульно отображающие многоязычные строковые реквизиты на текущем языке, создаются интерактивно на форме при разработке объекта, по определённым правилам (отказ от программного добавления позволяет кастомизировать визуальное представление многоязычных реквизитов под каждый объект). Для удобного доступа к реквизитам на разных языках в отчётах в пользовательском режиме подключён механизм характеристик (видами характеристик являются пары «Язык» + «Имя реквизита», объединённые в единый ссылочный ключ, а значением – представление). Ограничение текущей реализации – набор строковых реквизитов для которых требуется поддержка многоязычности закладывается при разработке объекта метаданных и жёстко зашит в коде.
3) Простота поддержки – при разработке объекта метаданных с поддержкой многоязычности, определяется обязательный набор реквизитов и процедур, которые он должен содержать, вся логика процедур, обеспечивающая механизм, выносится в универсальные общие функции, в модулях объекта происходит только их вызов с нужными параметрами. Спец. реквизиты формы, необходимые для поддержки механизма, добавляются при создании формы программно, если не требуется их визуального отображения на форме (см. пункт 2).
4) Опциональность механизма – в системе создана функциональная опция «Поддерживать многоязычность данных», если она выключена, то обращение к процедурам механизма многоязычности не происходит, все события отрабатывают стандартным образом, данные по представлению берутся непосредственно из реквизитов.
Мультиязычность данных можно рассмотреть и под другим углом: система должна говорить с пользователем не только на одном языке, но и понятными ему терминами. Отсюда вытекает новая задача — заложить в систему механизмы обеспечивающие поддержку профессионального сленга данных.
Поясню, что имеется в виду на примере:
Есть некий мастер цеха, который ждёт поступления особого металла пригодного для изготовления обечайки. В спецификации на изготовление обечайки и прайсах поставщиков данный металл проходит под названием «Металл М1287». Для ответственного по закупкам этот металл должен оставаться металлом М1287, а для мастера цеха – «металлом для обечайки».
С технической точки зрения механизм поддержки сленга, включает в себя все требования, предъявляемые к механизму многоязычности данных и может быть построен на его основе (включая способы хранения и получения представления)
Различия этих двух механизмов проявляются в 2х моментах:
- При работе со сленгом добавляется новый разрез – контекст, в котором получается представление объекта (должность пользователя, функциональная область системы, в которой он в текущей момент работает)
- Различается способ ввода данных:
для многоязычности — ввод данных осуществляется на текущем языке пользователя, поддержка перевода элементов на другие языки базы – отдельная регламентная функция специального отдела;
для сленга – ввод разных представлений осуществляется через словарь, который может формироваться в том числе и программно (например, для металла М1287 – автоматически формируется запись в разрезе мастера цеха при составлении спецификации изготовления обечайки)
Выводы
Т.о. на многоязычность системы можно смотреть с разных точек зрения, в комментариях предлагаю обсудить бизнес потребности в таких механизмах и их техническую реализацию.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Скачал, посмотрел
Интересно
Выводы:
1. Проект Доминикана — компании Первый БИТ
2. Разработку ведете на 8.3 Такси — радует
Насчет «многоязыковости» 1С интересно
Добавление языков в платформу 1C кроме стандартного списка (выбирается при установке), например, японский.
(3) Nykyanen, Если это по поводу (2), то язык из обсуждения — отсутствует в 1С — напрочь…
Насчет многоязычности бизнес-потребность точно есть. Помню, писали конфигурацию для Китая, а переводчики потом в скобках наименования элементов форм на китайском дописывали, так как в Китае и русские и китайцы в базе работали. Насчет слэнга сомневаюсь, что есть такая потребность, так как во-первых можно так же в скобках в наименовании указать все варианты как то: Металл М1287 (для обечайки). Во-вторых сленговые представления могут бизнесу помешать, если тот же мастер цеха позвонит ответственному по закупкам и спросит: «когда мой металл для обечайки привезут?» Что на это должен ответить закупщик? «мы никакой обечайки не заказывали, только металл1287»?
(5) a-novoselov
Во-вторых сленговые представления могут бизнесу помешать, если тот же мастер цеха позвонит ответственному по закупкам и спросит: «когда мой металл для обечайки привезут?» Что на это должен ответить закупщик? «мы никакой обечайки не заказывали, только металл1287»?
Спасибо. Нас тоже беспокоит этот вопрос. Мы видим два выхода:
1. Это все же отдельные поля (например, наименование и артикул) и оба пользователя видят все (как есть сейчас в конфигурациях);
2. Общение между такими пользователями должно выполняться через «руководителей», которые знают оба названия. Как и для понимания названий на разных языках, нужен человек знающий оба языка.
Сейчас мы попробуем второй вариант.
(6) frying,
Либо общение между такими пользователями должно происходить через систему:
мастер цеха отправляет задачу ответственному по закупкам — «уточнить дату привоза металла для обечайки», а тому приходит задача уже переведённая на понятный ему «язык»
(6)
Думается мне, что у руководителей есть дела поважнее, чем переводить наименования справочников своим или чужим подчиненным.
(9) a-novoselov,
У Вас есть какие-нибудь предложения, как они смогут «говорить» на одном языке?
(9) Делать у объектов одинаковые представления в рамках одного языка. Да и для разных языков, желательно, предусмотреть возможность получения представления на другом языке, чтобы можно было общаться с коллегами, работающими в этой же базе на «их» языке. Мне кажется для пользователей это было бы очень удобно.
Интересная идея — ввести поддержку сленга. Только вот как он будет работать в рамках программы? Ведь сленг свойственнен прямому общению между людьми, причем зачастую важен контекст, в рамках которого используется. Наверняка все сталкивались с фразами типа (18+) «Васёк, подай мне вон ту хрень, а то вот эта фиговина не хочет закручиваться!» — и «Ваську» понятно, что от него хотят получить, так как он видит и «фиговину» и все «хрени» которые есть рядом и могут помочь в данном случае.
Теперь подумаем про программу: у металла М1287 вполне могут оказаться аналоги A622 и SPHE, но все они являются «металлом для обечайки». Как мастер цеха определит, что для изготовления текущей партии обечайки надо использовать «вон тот» металл? Думаю, что сленг целесообразно использовать для должностей, которые находятся на разных «уровнях».
Например: Ответственный по закупкам должен четко понимать что ему надо заказать у поставщика металл М1287. Мастер цеха тоже должен четко понимать, что вот эта обечайка будет сделана из металла М1287 чтобы выписать ее со склада. А вот рабочий, который делает эту обечайку вполне может себе думать, что он работает с «металлом для обечайки». Да и руководителю организации можно в отчетах выводить информацию, что вот у этого контрагента «металл для обечайки» дешевле чем у этого, но (!) с возможностью уточнить марку/артикул по каждой позиции.
Не вижу причин, почему специалисты на всех уровнях не могут говорить на едином профессиональном уровне: металл 1287 для всех металл1287. Между собой как угодно можно называть материалы, да и в описаниях к материалам в системе тоже. Ведь существует строгая технология производства, и там ошибиться сложно.
Если есть возможность приучать людей делать так, чтобы программисту не надо было делать ничего в 1с, а не каждую хотелку каждого удоволтворять. Ясно — понятно, что не надо перегибать, все в пределах разумного. Вобщем надо немного «попинать» работников.
(10)(11)(12)
Спасибо за высказанные мнения. Мы попробуем решить описанные проблемы и неудобства.
Ещё, меня сильно «достает», что когда делаещь несколько языковых интерфейсов, то если забыл (пропустил, …) что-то то отображается «пустое место» — вместо «языка по умолчанию».
(15) AnryMc, в выложенном примере многоязычность данных реализована именно так: если текущий язык для реквизита не определён, то выводится значение основного языка. Также, если нажать на «лупу», можно увидеть значения реквизита на всех языках.
Насколько я понимаю в системе планируется работа всех сотрудников предприятия, от низшего звена до руководителя.. возвращаясь к вопросу с сленговыми представлениями ДАННЫХ, все правильно сказали выше, неплохо было бы делать это опционально вообще, ведь когда то рабочий станет мастером, а мастер может станет рукводителем цеха и тд, а значит их нужно «подтягивать» до уровня высшего звена… раз они будет работать с системой нужно опционально показывать что металл для обечайки это М1287, как то так… да, вот еще, с данными более менее понятно, а вот как быть с представлением реквизитов в отчетах (формах) ? ведь для рабочего слово Номенклатура будет непонятно, а для бухгалтера непонятно почему Номенклатура называется Материал (он сочтет систему безграмотной)… не будете же вы делать разные отчеты (формы) для разных сотрудников по компетенции ?
PS: по поводу аналогов материалов и сленга, тут еще видется проблема, зачастую как говорили выше М1287 может быть ADBCD или M1234 и тд, но технологический процесс обработки будет меняться от того какой именно металл был доставлен, возможно где то надо нагреть сильнее, где то давление, где то каких то ингридиентов досыпать… а если рабочий не будет знать какой именно металл доставлен? он испортит изделие из за системы! или что, мастер должен ходить и по всему цеху и контролировать как идут тех. процессы на разных линиях с разными металлами ?) Тут надо подумать однозначно насчет сленга, когда то он просто вреден будет!
(5)
В общем случае Вы правы: закупщики могут и не знать под что закупаем сырье/материалы. В таких случаях сленг производственников не «обнимает» закупщиков, обнимает складских и производство. И от этого сужения области действия является не менее полезным.
Более того: свой сленг может жить только на складах или только в производстве, и даже в этом случае тоже остается полезным и бизнесу не мешает уж точно. А скорее помогает потому что люди чувствуют что система говорит с ними на одно языке, своя в доску, ей можно доверять.
(11)
Нет не так. Металл для обечайки только один. Это специально сваренная сталь, которая прошла контроли, в том числе внешними контролирующими органами, получила сертификат соотвествия, который (наряду с другими документами) будет сопровождать изделие весь жизненный цикл. На всякий случай. Скажем при аварии будут выяснять соотвествовал ли металл требованиям, кто проверял и т.д.
(11)
(11)
По маркировке, а также в случае необходимости по результатам анализов, которые выполнит лаборатория
Никто не сможет получить этот металл на другие нужды
Таковы требования производства
Да, совершенно четко понимает: у него есть полная и точная спецификация, на основании которой будет проведена сталь
См. выше — строго говоря это уже не вопрос мастера — за него все решили, проверили и металл на складе — под обечайку
Поэтому он тоже работает с «металлом для обечайки».
Точнее так: спецстали у этого завода дешевле чем у другого, качество и сроки- лучше у такого-то, транспотные издержки — у такого-то. В прошлый раз закупали у такого-то — нареканий не было. По совокупности факторов следует брать у такого-то
(18) Анатолий Андюкин, не согласен, в плане того же металла один и тот же по качеству металл может называться по разному только в зависимости от типоразмеров «круга» в котором он приходит, или по толщине бруска и тд.. а вы еще не забывайте хим. производство, там еще сложнее с ингридиентами… так что совакупно «металл для обечайки» не значит что это именно М1287, был опыт просто и не раз на производстве подобном, в том числе и на сталелитейном/металлообработка.
ПС: кстати про сленг, на реальном производстве мастер скорее знает что такое М1287, и куда его и в каком количестве надо.. а вот заказчиккладовщик скорее нет, для них это просто набор букв и цифр. Так что кому будет удобен сленг это еще большой вопрос
(20) полностью согласен.
Анатолий (19), я в курсе, что Вас сложно переубедить, но я полностью согласен с (20) и придерживаюсь точки зрения, что обечайка (надеюсь все здесь воспринимают это слово как образ, а не как конкретное изделие) может производиться не только из одной марки металла.
(20), (21) — пример это, конечно, некий образ, причём этот образ строился как раз вокруг того, что в конкретный момент времени для конкретного человека сущность со сленговым представлением однозначно определена как для системы, так и для человека. Т.е. в примере мастер цеха и система однозначно понимают под «металлом для обечайки» металл М1287. Если это не так (однозначного понимания человеком или системой нет), то, естественно, сленг в таком случае не применим.
(22) Т.е. система будет представлять мастеру цеха металл М1287 как «металл для обечайки» пока тому так удобно и понятно. Если появится аналог металла М1287 или сам мастер цеха станет мыслить категориями артикулов, то система тут же должна перестроится.
Цель задумки поддержки сленгов — сделать систему более «человечной». Насколько это будет востребовано — пока не ясно, но, на мой взгляд, опциональная возможность наличия такого механизма интересна, естественно, при должном качестве его реализации, чтобы он был адекватен и предсказуем.
(23) данная возможность, как опция, несомненно интересна. Только вот настройка данной возможности на мой взгляд будет сложнее чем плюс от ее использования. Ведь если многоязычность можно реализовать путем добавления в программу словарей или с использованием онлайн переводчиков, то слэнг надо будет настраивать вручную. И должен это делать человек, который знает все слэнговые особенности предприятия на 5+. Иначе может произойти неприятность.
(23) согласен с 24 что настроить будет сложновато, хотя затея интересная. И все же, мне больше проблема видется имено в наименованиях реквизитов Номенклатура-Материал-ТМЦ, Покупатель-Контрагент-Плательщик и тд… в 17 спрашивал об этом… как собираетесь реализовывать?
(25) AllexSoft, не обратил внимание на этот вопрос в (17) посте, а тема действительно интересная.
Представление объектов метаданных в зависимости от контекста — это отдельная задача, в этой публикации я её умышленно не коснулся, т.к. нет понимания как её реализовывать.
Средствами платформы можно корректно переопределить заголовки форм в зависимости от контекста (Номенклатура-Материал-ТМЦ), с надписями на формах всё намного сложнее, а вот заголовки команд вообще не поддаются программному управлению.
Обсуждался вариант хранения разных заголовков в отдельных языках конфигурации, которые будет наследоваться от основного, но в этом подходе помимо очевидной проблемы, что нельзя настраивать базу в режиме «Предприятия», есть и ещё одна — язык в конфигурации зависит только от измерения «Пользователь», а для хорошей контекстозависимости этого не достаточно.
(26) исходя из статей, посвященных будущему интерфейсу разрабатываемой системы, можно сделать вывод, что интерфейсная часть будет реализована средствами HTML + js? Зачем тогда думать над тем как задавать заголовки команд, если интерфейс будет реализован сторонними средствами?
(27) При решении о разработке того или иного механизма учитываются разные варианты развития системы. Создание альтернативного интерфейса для 1С находится на стадии НИОКР и закладываться только на него было бы недальновидно, речь в этой статье шла о представлении данных и объектов в типовом интерфейсе 1С.
Хотел ответить, но Ярослав уже ответил.
(28) ясно
Считаю идею про сленги преждевременной. Во-первых, многоязычность более важна и востребована сегодня. Во-вторых, реализация одной только многоязычности потребует много усилий. В-третьих, поддержание актуальных сленгов будет трудоемкой задачей. В-четвертых, отсутствие сленгов никоим образом не помешает предприятию работать. Сама трудоемкость указания сленгов приведет к тому, что этой функцией никто не будет пользоваться.
Поделитесь соображениями… В примере реализации по производительности в объект добавляются реквизит яМногоязычниеПредставление с сериализованными представлениями и табличная часть МногоязычниеПредставление, которая используется для более быстрого поиска. Почему нельзя использовать только реквизит или только табличную часть? Что сериализованный реквизит дает такого, чего нет в табличной части?
(32),
>Почему нельзя использовать только реквизит или только табличную часть? Что сериализованный реквизит дает такого, чего нет в >табличной части?
В обработчике ОбработкаПолученияПолейПредставления, нельзя обратиться к табличной части, поэтому пришлось делать реквизит.
Табличная часть нужна, чтобы построить индекс по представлению, иначе, например при вводе по строке, получили бы сканирование всей таблицы. В случае большого объема данных, это значительно скажется.
(33) frying, это связано с особенностями управляемого приложения? Для обычного приложения думаете функционал многоязычности придумывать? Использование обычного приложения будет актуальным еще несколько лет.
(34), механизмы платформы по получению представления, которые используются, вроде как работают в любом режиме.
Наименование элементов справочников должно иметь аналоги на других языках. Если пользователь иностранного языка в форме списка вводит наименование на немецком, то должен выполняться поиск по немецкому наименованию, а не по русскому. Над такой задачей Вы думали?
(36) bsuray, у пользователя в параметре сеанса хранится язык данных, который является для него родным. Представление справочника в форме списка выводятся на этом языке и, соответственно, поиск осуществляется на нём же.
В прикреплённой к статье демо-базе можно посмотреть реализацию.
Представление на разных языках — это новшество платформы 8.3. У 8.2 такой возможности нет.
(38) bsuray,
(38), (39) bsuray вероятно имел ввиду механизмы получения представления данных, которые появились в 8.3
Всё верно, всё вышеописанное основывается на последних возможностях платформы, которые были доступны на момент опубликования статьи.
YOr!k понял правильно мое сообщение.
(37)
В прикреплённой к статье демо-базе можно посмотреть реализацию.
спасибо, не знал о таком, то есть получается для каждого элемента справочника я могу хранить несколько наименований? К примеру элемент справочника «номенклатура» — «книга», тогда в справочнике у меня будет название «книга» для русского, а если у пользователя английский интерфейс стоит — то название будет «Book»?? Я верно понял? Здорово если так.
Но тогда следующий вопрос возникает. Если я — двуязычный пользователь. Для русского рынка я буду продавать этот товар под именем «книга», а на англоязычном буду товар заказывать как «Book» — мне нужно будет как-то с интерфейса на интерфейс переключаться?
Также крайне неудобно системные названия вызывать только при запуске. Типа «Файл — сохранить как» и «File — save as». Почему это нельзя в настройки пользователя вытащить ((
Плюсанул статью
(42) Alex_Japanese_Student,
Всё верно
Правильно ли я понимаю, что мы говорим об условных документах «Продажа» и «Покупка» — один из них создаётся для контрагентов из одной языковой зоны, а второй — для другой? Оба документа будут вводится и отображаться пользователю на языке сеанса, а вот печатные формы для документов можно разработать так, чтобы была возможность печатать их на любом доступном языке.
Ещё замечу, что если для номенклатуры в учётной системе введены названия на обоих языках, то пользователю будет показываться название на языке текущего сеанса, а если, например, русский синоним не введён, то номенклатура будет отображаться на английском.
(43)
Ещё замечу, что если для номенклатуры в учётной системе введены названия на обоих языках, то пользователю будет показываться название на языке текущего сеанса, а если, например, русский синоним не введён, то номенклатура будет отображаться на английском.
с представлениями — это здорово, это реально шаг вперед, спасибо за информацию.
Но — ложка дегтя есть. Потому что надо все же иметь возможность видеть разные названия для одного сеанса. Ну вот простой пример. Я ввожу новую позицию «книга» в справочник «Номенклатура». Логичным будет сразу внести и английское название. И знания позволяют мне это сделать — я двуязычный пользователь. Но — система мне этого не дает.
Если английский не введен, то будет русский — вот это абсолютно правильно. Что-то всегда лучше, чем ничего. А если три языка, или допустим — 4? Два заполнено и два нет. Что покажет система?
Да вы все верно поняли. Зачастую один человек получает заказ от покупателя, вводит на русском, а потом составляет заказ поставщику — на английском. Поэтому банально неудобно переключаться туда-сюда.
(44) Alex_Japanese_Student,
Есть такая возможность, для этого надо нажать на «лупу» в поле ввода многоязычного реквизита (решение сделано аналогично вводу многоязычных представлений метаданных в конфигураторе)
Если представление на текущем языке пользователя не заполнено, то система покажет представление на основном языке, который устанавливается для системы в целом; если представление и на основном языке не заполнено — то первое попавшееся заполненное представление
Сами формы документа, на мой взгляд, нет необходимости видеть на разных языках, достаточно родного языка оператора, не зависимо от того для кого этот документ предназначается(пользователь другой языковой зоны увидет его на своём языке).
Для данной задачи достаточно возможности распечатать печатную форму документа на нужном языке, не переключая язык сеанса.
(45)
ага, вот это очень правильно. Если хоть где-то заполнено — то выводить. А где устанавливается основной язык системы?
формы — нет необходимости. Названия элементов справочников — есть, имхо.
Например, я готовлю сделку по продаже сложного технологического оборудования, с описанием в технических терминах. Если где-то будет ошибка — в русском названии, в английском — то просто или покупатель не примет, или поставщик не то завезет. Поэтому оператор должен контролировать это. И желательно — еще до печатных форм.
Ну и да — все же в печатных формах должен быть выбор — печатать на русском или на английском. Потому что в программу для этого перезаходить это как-то не комильфо.
(46) Alex_Japanese_Student,
В константе
Например, я готовлю сделку по продаже сложного технологического оборудования, с описанием в технических терминах. Если где-то будет ошибка — в русском названии, в английском — то просто или покупатель не примет, или поставщик не то завезет. Поэтому оператор должен контролировать это. И желательно — еще до печатных форм.
Пользователь всегда может поменять язык, поменяв текущее значение параметра сеанса, для этого не нужно перезаходить в программу, достаточно просто зайти в настройки пользователя.
(47)
вы знаете — я насколько понял из ваших ответов, вы предполагаете одну вещь.
что пользователь в массе одноязычен. То есть вот есть один конкретный пользователь — и у этого конкретного пользователя только один язык. Только этот язык ему нужен и только с ним он работает.
По практике реальной работы — это не так. Если элементы интерфейса можно иметь на родном для пользователя языке — то элементы справочников, данные все же достаточно часто как минимум в двух языках требуются — в родном для пользователя и на английском, как языке межнационального общения.
При использовании более 2х языков, такая система может сработать некорректно, например если представление на текущем язке пользователя не заполнено, а основной язык системы он не знает или знает плохо. В таком случае, для пользователя логичней сделать выбор хотя бы 2х языков: основной и вспомогательный, либо выстроить порядок предпочтений по языкам.
Насколько данная разработка притормаживает работу базы?
Это не разработка, это концепция, не более того
(45) (44) Alex_Japanese_Student, (51) AllexSoft,
Подскажите пожалуйста, правильно ли я понял, что в 83 можно вводить наименования справочников на разных языках?
Если да, то как. Я открываю любой справочник и при нажатии на лупку в поле наименование открывается окно с текущим наименованием. А ведь в 45 открывается форма с вводом наименования на разных языках.
Используется платформа 8.3.6.2041 без совместимости с 8.2. В конфигураторе 2 языка: русский и инглишь.
Как добиться открытия формы ввода наименования на разных языках?