Подскажите кто реализовывал мультиязычность для реквизитов справочника.
Допустим есть поле выбора где пользователь указывает язык.
И на форме нужно обновить(переключить) вывод данных на другой язык.
Как лучше реализовать это ?
Как хранить данные. Выводить на форму ?

Навижн, ФоксПро, семёрка или бюджетка?

8 платформа это предусматривает, в типовых не встречал. Идея примерно такова - у пользователя выбирается язык интерфейса, в нужных полях экранных форм задаётся синонимы на нужных языках.

(1) 1с8. Мне нужно данные хранить в разрезе языков. А не название реквизитов :)

(2) Данные уходят на сайт. Сайт поддерживает мультиязычность. Хотят что бы все это чудо паровоз шел с 1с.

(2) т.е. один и тот же реквизит может иметь несколько значений на разных языках!?

(4) да

(5) фигасебе, а куда это все писать?

(5) Думал свойства. и динамически рисовать на форме. при переключение пользователем языка. ему отображались эти реквизиты. Пока думаю ПВХ и РС

ну делай регистр сведений + справочник языков, делов-то

(8) Тогда с УТ 11 слизать и добавить реквизит язык. и доделать помощника при создание что бы могли выставлять для каких языков нужно создавать

Вариантов то не много :(

Хотя можно не РС. а табличную часть справочника и в нем хранить свойства и значения. меньше связей к таблицам будет

(9) что слизывать? мультиязычность заголовков реквизитов это платформенное

но тебе же не это нужно

(13) Слизывать отображение свойств в УТ11. они рисуются динамически и распологаются на форме элемента номенклатуры.

(14) как реквизиты

(14) ты про доп реквизиты чтоли?

(16) часть возможно стандартных. а часть доп

(17) не ну попробуй конечно, только имхо это совсем не то - намучаешься с их расположением на форме, в УТ это тупо вертикальная группировка

(0) вот так не подойдет (как пример)
https://clck.ru/AAfDR

(18) Да вот я думаю. Что лучше. Потом же этот паровоз сопровождать.

(19) Это представление названий реквизитов. А мне нужны данные на разных языках :)

(21) имхо лучше сделать скульную БД, в нее выгружать из 1С и спец обученная девочка там же будет все переводить

оттуда и на сайт закидывать

по-моему, решение для хранения простое - регистр сведений "Язык-ЭлементСправочника-ИмяРеквизита"=>"Значение". А реализовать вывод в поле (и сохранение в этот регистр) в зависимости от языка можно в расширении, переопределив в расширении методы ПриСозданииНаСервере() и ПриЗаписиНаСервере()

(23) тогда уж несколько РС ибо один будет огроменный

(24) А если n языков :)

(22) так хотят в 1с. так бы на сайте все заполняли. А хотят от этого отойти.

(24) почему он будет огроменный? Там будет всего то (ЧислоСсылок)*(ЧислоЯзыков)*(ЧислоРеквизитов) записей

(19) Поправь опечатки:
еврит -> иврит
файлеревода -> файл перевода
Нужно подробности -> Нужны подробности
раскроем и убедится -> раскроем и убедимся
в одно месте -> в одном месте
я ждет -> и ждет
заполняем значение -> заполняем значением
что нужен ОБЯЗАТЕЛЬНО перевести -> что нужно ОБЯЗАТЕЛЬНО перевести

А ещё надо бы пунктуацию поправить и вот этот набор слов: "Чтобы ваш перевод сохранился или вам удобнее делать перевод отдельно."

Столько реквизитов, сколько языков. Примеры: НаименованиеРус, НаименованиеEn, НаименованиеНац, НаименованиеЛат и т.д.

(21) Во-первых, для пользовательских данных нет тиражных инструментов автоматического перевода. Разумеется, автоматический перевод можно использовать как подстрочник для ручного, но это не сильно спасает на большом массиве информации.

Во-вторых, проблема по-любому упирается в способ хранения словаря в виде значений матрицы типа:
Справочник - Элемент справочника - Наименование на языке1 - Наименование на языке2 - Наименование на языке3..
Например, можно воспользоваться вариантами, предложенными в (22) или (29), а также придумать своё собственное "местохранилище" (РС, другие БД, внешние файлы и пр.) Во многом это будет определяться теми данными, которые нужно переводить и хранить.

В-третьих, словарь должен быть пополняемым, т.е. каждое новое значение элемента справочника нужно перевести на все необходимые языки. Следовательно, обязательно нужен мониторинг на наличие терминов в словаре по сродству стрингов.

В-четвертых, переводить лучше одному человеку. Причина проста: толпа накосячит (даже профессиональные переводчики со страшной силой врут в специальных областях). Или, как вариант, переводчиков может быть несколько (и пусть хоть по API автопереводят), но ответственный за конечную редактуру терминов, ввод их в словарь и содержание словаря должен быть один. А это вообще не техническая проблема, а организационная сродни профилактике дублей в справочниках.

Замечу, что знаю ребят, которые пытались в той или иной степени это реализовать - могу с ними познакомить для обмена идеями. Но, сразу предупреждаю, как правило, это был один язык. Также могу показать свою старую разработку на 7.7 с пополняемым словарём (просто как информацию к размышлению).

В заключение могу пригласить в команду разработчиков, которая сейчас Small Business (УНФ на английском) адаптирует для Европы - там будет много языков, и рано или поздно та же проблема возникнет где-нибудь в Швейцарии, где 4 государственных языка. Тут то мы друг другу и пригодимся! :)

(30) А эта команда, "которая сейчас Small Business (УНФ на английском) адаптирует для Европы" - это филиал российского франча с офисом за рубежом?

(0) Предлагаю объединить усилия с коллегами из ветки "Перевод данных на разные языки": Перевод данных на разные языки
:)

(31) В проекте принимают участие как франчи, так и частные лица. Состав регионов "коллаборантов" указан в анонсе доклада Алексея Снитковского "Международный Проект - разработка продукта для управленческого учета на базе 1C:Small Business (первая международная типовая)" на странице конференции Инфостарт: http://event.infostart.ru/2016/?utm_source=portal-ie2016dev&utm_medium=banner&utm_campaign=speaker&utm_term=portal-topline