Реализация возможности смены языка в клиенте

В Лабитеке решали такой вопрос. Можете попробовать связаться с ними.

Интересуют непосредственно варианты перевода справочников:)

Специально такое разрабатывать сейчас, скорее всего, никто не будет. Спросите у них.

Да никто не просит.
Я и спрошу, и разработаю:)
Вопрос был к тем, у кого был опыт и идеи для дальнейшей дискуссии по интересам.

По справочникам (правда, в другом продукте) делали дополнительную таблицу
-ObjectId
-RecordId
-LanguageId
-Name

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

Соответственно, в каждом справочнике деталь с языками и названиями

Ещё, говорят, были мысли о китайской локализации. Но вовремя одумались, осознав масштаб работ.

Владимир, аналогично себе это и представлял, вплоть до View.
Проект интересный, по результатам, либо возникающим вопросам - отпишусь:)

"Нестеров Артем Валерьевич" написал:Проект интересный, по результатам, либо возникающим вопросам - отпишусь:)

Проект интересный и очень объемный, так что можно блог писать :D

а в bpm'online 7 такой вопрос кто-то решал?

Есть русская версия, есть английская. А как бы объединить, давая пользователям возможность переключаться между интерфейсами?

Владимир, мультиязычие пока что не предусмотрено. Данная задача будет реализована в версии 7.8.0.

"Демьяник Алексей Олегович" написал:Данная задача будет реализована в версии 7.8.0.

Какая отличная новость для нашего мулти-язычного региона!

Работа кипит.
Нужна функция, которая собирает все названия датасетов окна в массив.

Такой функции, скорее всего, нет. Можете её написать.
Можно по аналогии с функцией GetControlByDataFieldName из scr_DB, только в цикле искать не визуальные компоненты, а даталинки.

function IsDataControl(Control) {
	var DatasetLink = Control.DatasetLink;
	var DataFieldName = Control.DataFieldName;
	return ((DatasetLink != undefined) && (DataFieldName != undefined));
}
 
function GetControlByDataFieldName(Window, DataFieldName) {
	for (var i = 0; i < Window.ComponentCount; i++) {
		Component = Window.Components(i);
		if (IsDataControl(Component)) {			
			if (Component.DataFieldName == DataFieldName) {
				return Component;
			}
		}
	}
	return null;
}

Так как лучше сделать вывод перевода справочников?
Создан один большой общий глобальный справочник для джоина на него остальных -
ID (ид записи)
ItemID (ид записи присоединяемого справочника)
LanguageID (язык перевода)
Name - (Собственно сама строка перевода)

Тут всё понятно, без проблем.
А вот как сделать вывод перевода из этого справочника в необходимом окне, при этом и при этом не потерять стандартный функционал для заполнения - вопрос.
На текущий момент решение (но мне не очень нравится):
1.Джоиним каждый справочник на справочик переводов
2.В каждом переводимом справочнике создаём колоночку(TName, для того, чтобы не убивать стандартный Name из функционала заполнения. Эта колонка нужна для того, чтобы была возможность заджоинить сам справочник на необходимое окошко и подогнать в неё данные selectquery по параметрам джоина)
3.Используем данные из этой колоночки в сервисе окна

Можете несколько месяцев подождать и сделать структуру базы аналогично 7.8.

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

"Можете несколько месяцев подождать и сделать структуру базы аналогично 7.8."
Только здесь и сейчас :-D
Ок, значит будем первооткрывателями.

Как можно реализовать подмену данных Name в справочнике?
Если банально в справочнике писать SQL Text column(с идентичным запросом) вместо обычного типа Name, то террасофт вываливается с ошибкой OLE Error, хотя в SQL студии всё работает корректно.
Более того, данные в Lookup Data Control всё равно тянутся из первичной колонки для отображения, не с SQL запроса в подмене Name.

Можете сделать справочник по view вместо таблицы.

И что нам это даст?
У меня проблема сейчас в том, что я подменил выбор поля Name в справочнике текстом запроса.
При открытии самого справочника - всё хорошо и корректно данные подтягиваются, а вот при попытке вывалить список LookupDataControl - валится ошибка, непонятно с чего.

Почему, если скажем в tbl_Dictionary выбирать Name как обычной колонкой в сервисе, то все лукапдатаконтролы прогружаются нормально, а если написать выбор Name как SQL Text column [tbl_Dictionary].[Name], то в самом справочнике прогружается нормально, а вот при загрузке контроллов спровочника в других окнах всё валится с ошибкой?

Ну, значит так нельзя делать. Пробуйте другим способом. Возможно, получится с колонкой подзапроса или ещё как-то.

Попробовал воспроизвести, в какой-то момент было сообщение о несовместимости типов. Возможно, в ядре для колонок различного типа (обычная, SQL и др.) используются разные классы данных.

С колонкой подзапроса аналогично

В таком случае ищите другие способы. Штатно никто такое со справочниками не делал.

Господа из ТС ничего не ответят по данному вопросу?

Платформа 3.Х уже несколько лет не развивается, так что маловероятно, что господа из ТС будут что-то глобально переделывать в ядре под такое специфическое использование.

Мне фактического подтверждения ошибки и объяснения процесса было бы предостаточно.

Это не ошибка, в системе Terrasoft 3.X не предусматривалось использование нескольких языков в справочниках. Это уже Ваши разработки.

Сами же говорили, что:

Знаю, что не предусмотрено, знаю что много и долго, но...