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

I

imendan

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

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

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

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 236
28
а чем через профили плохо?
 
lmike

lmike

нет, пердело совершенство
Lotus team
27.08.2008
7 259
439
Вот бы что-нибудь подобное можно было бы сделать в 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) - сразу можно вывести название поля и не хардкодить
 
  • Нравится
Реакции: NetWood и alexas1
garrick

garrick

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

Gandliar

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
7 259
439
Если поставить птичку в свойствах базы, что она многоязычная, то можно сделать для каждого языка свой элемент дизайна с одинаковым названием. таким образом, в зависимости от языка в настройках лотуса будут подтягиваться нужные элементы дизайна.
можно, но очень гиморно (лазить оп формам и править перевод)
 
K

kolka

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

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

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

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

alexas1

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
7 259
439
не делать на каждый ключ-значение отдельный док
мною это было сделано как раз для локализации чекбоксов/комбобокстов, т.к. там многозначное поле д.б.
[doublepost=1496564728,1496564567][/doublepost]
если язык системе неизвестен и вернулось пустое значение
это повод узнать что нет локализации и у меня возвращает название поля (это позволяет увидеть - что еще нужно локализовать)
 
K

kolka

Happy New Year
16.02.2013
31
5
Общее кол-во профайлов тоже ограничено.
Насколько я помню, проблемы примерно после 2000 начнаются. Если требуется 20 элементов на 100 языков положить, то соглашусь, лучше не связываться.

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

lmike

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

kolka

Happy New Year
16.02.2013
31
5
если поле названо, как это и полагается, на понятном английском языке - то его и увидит, что нормально
а для чего, иначе, нужны названия полей - чтобы запутывать разрабов? ;)
[doublepost=1496746367,1496746262][/doublepost]можно и вовсе - ссылку для юзера казать - для самостоятельной локализации ;) (зависимо от роли в БД)
Вспомнился старый баян "не давайте програмерам самим дизайнить пользовательский интерфейс" :)
*не убедил*

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

lmike

нет, пердело совершенство
Lotus team
27.08.2008
7 259
439
Вспомнился старый баян "не давайте програмерам самим дизайнить пользовательский интерфейс" :)
*не убедил*

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

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

kolka

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

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