• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

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

    Запись на курс до 25 апреля. Получить промодоступ ...

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

imendan

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

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

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

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
216
Вот бы что-нибудь подобное можно было бы сделать в Lotus-е. Вопрос чисто по клиенту Lotus Notes. По XPages вроде проще.
уже постил здесь
на форму выносите КФД, вместо названий, в бд вьюшку - с разными языками
формула типа:
key:=cLocale+"|fld|"+@LeftBack(@ThisName;"_");
v:=@DbLookup("":"ReCache";"":"";intlView;key;cIntl);
@If(@IsError(v);@ThisName;v)
локаль вычисляем (для русского даст "ru")
@LanguagePreference([AlternateName])
при этом она задается в преференсах (если системная не устраивает)
upload_2017-3-23_16-28-23.png

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

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

garrick

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

Gandliar

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

lmike

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

kolka

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

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

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

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

alexas1

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

lmike

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

kolka

Green Team
16.02.2013
32
7
BIT
0
Общее кол-во профайлов тоже ограничено.
Насколько я помню, проблемы примерно после 2000 начнаются. Если требуется 20 элементов на 100 языков положить, то соглашусь, лучше не связываться.

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

lmike

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

kolka

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

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

lmike

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

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

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

kolka

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

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

Обучение наступательной кибербезопасности в игровой форме. Начать игру!