Сергей, сама по себе мультиязычность обеспечивается механизмом схем с хранением данных на разных языках в отдельных записях специальных служебных таблиц (Sys...Lcz).

А по поводу того, как это интегрировать с актуализацией, всё зависит от конкретной системы, откуда берутся данные. Обычно у каждой страны есть свой стандарт, своя база, как правило, только на государственном языке, но есть и универсальные для нескольких стран. В маркете есть примеры таких коннекторов: Address database (для России, Украины, Казахстана), FIAS address hints (только РФ).

Спасибо) Не совсем то, что нам нужно. Когда сделаем - отпишусь.

Здравствуйте.

Локализировать нужные значения можно через раздел 'Переводы'.

Правда, в БП не все значения попадают в локализируемые.

EmailSender скорее всего берет тело сообщения из активности, а там уже лежит текст сообщения на каком то языке.

Почему бы не воспользоваться стандартным блоком "Отправить Email"?

Письмо должно быть привязано в хронологию обращения. К тому делал через отправку стандартным блоком Отправить Email и постоянно какие то ошибки. Не дружу я с ним )

К тому же все стандартные процессы по отправке писем не используют блок Отправить Email, а отправляют скриптами

Попробуй поигратся со сменой языковой культуры перед отправкой

Как то так

cultureId = UserConnection.CurrentUser.SysCultureId;

//cultureId бери из настроек пользователя те тот язык на котором хочешь чтобы было письмо пользователя

esq.SetLocalizationCultureId(cultureId);

Ну или более глобально как то так

userConnection.CurrentUser.SysCultureName = "en-US";

В итоге выяснилось путем тестов. Элемент БП Выполнить действие -  - Обработать шаблон письма с макросами не учитывает мультиязычные шаблоны.  Делал подмену шаблона из таблицы EmailTemplate на EmailTemplateLang. 

var mailTemplateID = Get<Guid>("MailTemplateID");
var usrLangId = Get<Guid>("UserLanguageID")==Guid.Empty
    ? new Guid("6EBC31FA-EE6C-48E9-81BF-8003AC03B019")
    : Get<Guid>("UserLanguageID");
var newMailTemplate = new EmailTemplateStore(UserConnection);
Set<Guid>("MailTemplateID", newMailTemplate.GetTemplate(mailTemplateID, usrLangId).PrimaryColumnValue);
return true;

И подавал на вход Элементу Обработать шаблон письма с макросами - результате пустое письмо. Поэтому перешел на другую отправку писем:

var contactEmail = Get<string>("ContactEmail");
var senderEmail = Get<string>("SenderEmail");
var caseId = Get<Guid>("RecordId");
var templateId = Get<Guid>("MailTemplateID");
var emailTemplateMacrosManager = new EmailWithMacrosManager(UserConnection);
emailTemplateMacrosManager.SendEmailFromTo(caseId, templateId, senderEmail, contactEmail);
return true;

Хорошо что раздел обращения. Полагаю в другом разделе такая отправка не заработает (

В схеме таблицы для тех полей, которые хотите локализировать, установить признак 'Локализируемый текст' (Localizable Text):

По умолчанию для таблиц, которые наследованы от Base lookup, для полей Name и Description эти признаки уже установлены.

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

Для примера на скриншоте ключ выглядит следующим образом: Data:Contact.OfficialName:82d21f9f-4cec-4ff7-aeee-9255cc4f37f3. Contact - это название таблицы, OfficialName - название локализируемого поля, 82d21f9f-4cec-4ff7-aeee-9255cc4f37f3 - Id записи в таблице Contact, для которой делается перевод.

Также учтите, что для перевода на нужный язык, он должен быть активирован в срм.

Спасибо!



Но есть дополнительный вопрос. При обновлении переводов показываются только те записи, которые были добавлены после отметки поля как переводимого.



А как все уже существовавшие записи добавить для перевода?

Посмотреть в профайлере, какие записи добавляются в какие таблицы при добавлении записей в справочник, а потом по всем старым SQL-запросом по аналогии?