Мультиязычный интерфейс

[imendan]

Приветствую, господа! Интересуюсь более удобными методами организации мультиязычного интерфейса. 2 метода, которые использую сейчас:
1. Через @Environment("LANG") = "RUSSIAN". Неудобство - чтобы изменить перевод или добавить новый язык, надо войти на все кнопочки, поля и т.д. и изменять. Долго и неудобно.
2. Через локальную базу данных. Проблема реплицировать новые значения с сервера на все локалки. Плюс грузит немного при открытии окна.

В Java есть очень удобная библиотека

Ссылка скрыта от гостей

Вот бы что-нибудь подобное можно было бы сделать в Lotus-е. Вопрос чисто по клиенту Lotus Notes. По XPages вроде проще.

 

[ToxaRat]

а чем через профили плохо?

 

[lmike]

Вот бы что-нибудь подобное можно было бы сделать в Lotus-е. Вопрос чисто по клиенту Lotus Notes. По XPages вроде проще.

уже постил здесь
на форму выносите КФД, вместо названий, в бд вьюшку - с разными языками
формула типа:

key:=cLocale+"|fld|"+@LeftBack(@ThisName;"_");
v:=@DbLookup("":"ReCache";"":"";intlView;key;cIntl);
@If(@IsError(v);@ThisName;v)

локаль вычисляем (для русского даст "ru")

@LanguagePreference([AlternateName])

при этом она задается в преференсах (если системная не устраивает)

[doublepost=1490275431,1490275275][/doublepost]ну наполняете доки названий для полей, с разными языками
у меня названия полей (подписи) соответ. имени поля _title

это удобно и для обработчиков ошибок в полях (в QS) - сразу можно вывести название поля и не хардкодить

 

[garrick]

Вы хотите иметь несколько языков в одной базе или несколько баз (клиентов) с разными языками? Для второго случая, не помню точно, у IBM или Team Studio была штатная штука для Lotus Notes - на старой работе практиковали.

 

[Gandliar]

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

 

[lmike]

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

можно, но очень гиморно (лазить оп формам и править перевод)

 

[kolka]

Создаются языковые профайл-документы с ключем-кодом языка ( en, ru,...). На форме вычисляемое CFD поле, которое возвращает язык пользователя/базы. Для вычисления можно использовать, например, Regional Settings, как выше lmike подсказал. Все лейблы тянут свои значения из языковых профайлов с двумя ключами - имя поля и язык, например: @GetProfileField( Form; fieldName; language ) Следует еще добавить подстановку значения по умолчанию на случай если язык системе неизвестен и вернулось пустое значение.

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

Если используете ComputeWithForm, то перед вызовом не забыть CFD поля ручками дописать с SaveToDoc = False.

Еще как вариант - доставать все языковые строки в одно поле парами "значение|ключ" при открытии и потом уже оттуда забирать всеми остальными CFD/CT.

 

[alexas1]

Общее кол-во профайлов тоже ограничено.
Способ lmike лучше.
Ток можно чуть модернизировать - не делать на каждый ключ-значение отдельный док, а писать их в многозначное поле и выводить в вьюшке values as separate entries

 

[lmike]

не делать на каждый ключ-значение отдельный док

мною это было сделано как раз для локализации чекбоксов/комбобокстов, т.к. там многозначное поле д.б.
[doublepost=1496564728,1496564567][/doublepost]

если язык системе неизвестен и вернулось пустое значение

это повод узнать что нет локализации и у меня возвращает название поля (это позволяет увидеть - что еще нужно локализовать)

 

[kolka]

Общее кол-во профайлов тоже ограничено.

Насколько я помню, проблемы примерно после 2000 начнаются. Если требуется 20 элементов на 100 языков положить, то соглашусь, лучше не связываться.

По поводу вьюшек,
ReCache ведь каждый раз будет индекс дергать, включая каждый рефреш на форме - просадка по производительности?
Что если приложение состоит из нескольких баз - в каждой делать поддержку, т.е. вью и все остальное?
_title поля - это ведь прилично отжирает место на имена полей.
Значения по умолчанию:

это повод узнать что нет локализации и у меня возвращает название поля (это позволяет увидеть - что еще нужно локализовать)

Вот тут, извините, не соглашусь. Если подключается пользователь с экзотической локалью, то что он увидит?

 

[lmike]

то что он увидит?

если поле названо, как это и полагается, на понятном английском языке - то его и увидит, что нормально
а для чего, иначе, нужны названия полей - чтобы запутывать разрабов?
[doublepost=1496746367,1496746262][/doublepost]можно и вовсе - ссылку для юзера казать - для самостоятельной локализации (зависимо от роли в БД)

 

[kolka]

если поле названо, как это и полагается, на понятном английском языке - то его и увидит, что нормально
а для чего, иначе, нужны названия полей - чтобы запутывать разрабов?
[doublepost=1496746367,1496746262][/doublepost]можно и вовсе - ссылку для юзера казать - для самостоятельной локализации (зависимо от роли в БД)

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

На самом деле кроме лейблов для полей есть куча других мест, где нужен перевод:
- заголовки секций
- заголовок формы/документа
- подсказки для ввода значений в поля
- текст для кнопок
- диалоги
- ...

 

[lmike]

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

На самом деле кроме лейблов для полей есть куча других мест, где нужен перевод:
- заголовки секций
- заголовок формы/документа
- подсказки для ввода значений в поля
- текст для кнопок
- диалоги
- ...

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

секции - редкое явление в моей практике, не считаю этот элемент необходимым именно для формы, в РТ - вполне себе...

 

[kolka]

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

секции - редкое явление в моей практике, не считаю этот элемент необходимым именно для формы, в РТ - вполне себе...

Мммм я вообще-то о ресурсах текстовых говорил. Конкретней - о значениях по умолчанию. Не суть важно где они (ресурсы текстовые) применяются, важно что они должны работать. И если в полях еще можно аргументировать "если поле названо, как это и полагается, на понятном английском языке - то его и увидит, что нормально", то что делать в остальных местах?

 

[lmike]

то что делать в остальных местах?

пример можно?
все что я выше описал - решается полями, либо не используется (например - подсказки, в классике)