Мультиязычная база и поиск

[NetWood]

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

Подход 1. Для каждого языка отдельный док с наборами переведенных текстов в полях и RTF. Языковые паттерны на вебе (меню, всякие словеса, алерты, конфирмы и пр) вынесены в отдельный .js который для каждого языка с набором одинаковых переменных. Переключается по кукам или стораджам одним полем с набором языков. Поиск можно сделать по каждому языку отдельно или вместе селектом во вьюхе. Это работает, мало полей в базе, стандартный подход, но неудобно в клиенте каждый док контролировать по набору языка, чтобы переключалось вот так: base/ru/pagename base/en/pagename base/pt/pagename/ Так сделан netwood.org

Обдумываю Подход 2. В каждом доке набор полей для каждого языка. Cкажем Title_EN BODY_EN Title_RU BODY_RU и пр. Удобнее редактировать в клиенте, но адок с полями. Для каждого нового языка надо добавлять поля, а не документ. Поля выводятся без проблем по языку из куки клиента, локалсторадж ets. Но есть проблем а с поиском. Можно указать во вьюхе 'каждое из нескольких значений отдельно', но все равно валится будет весь док и туда и туда, так как ищет индексер не поле, а документ. Это уже проходили. Как Исключить Поле Из Поиска По Представлению?

Вопрос. Вариант 2 с поиском на каждый язык = поле с языком жизнеспособен? ЧЯДНТ?

 

[savl]

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

А посмотри как в Marvel Client сделано, там что-то общее из этих двух.
и возможно вместо полноценных документов использовать Профильные или "новые профильные", которые теперь Named Documents. - Но тут не скажу за простоту работы с ними.

 

[lmike]

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

Подход 1. Для каждого языка отдельный док с наборами переведенных текстов в полях и RTF. Языковые паттерны на вебе (меню, всякие словеса, алерты, конфирмы и пр) вынесены в отдельный .js который для каждого языка с набором одинаковых переменных. Переключается по кукам или стораджам одним полем с набором языков. Поиск можно сделать по каждому языку отдельно или вместе селектом во вьюхе. Это работает, мало полей в базе, стандартный подход, но неудобно в клиенте каждый док контролировать по набору языка, чтобы переключалось вот так: base/ru/pagename base/en/pagename base/pt/pagename/ Так сделан netwood.org

Обдумываю Подход 2. В каждом доке набор полей для каждого языка. Cкажем Title_EN BODY_EN Title_RU BODY_RU и пр. Удобнее редактировать в клиенте, но адок с полями. Для каждого нового языка надо добавлять поля, а не документ. Поля выводятся без проблем по языку из куки клиента, локалсторадж ets. Но есть проблем а с поиском. Можно указать во вьюхе 'каждое из нескольких значений отдельно', но все равно валится будет весь док и туда и туда, так как ищет индексер не поле, а документ. Это уже проходили. Как Исключить Поле Из Поиска По Представлению?

Вопрос. Вариант 2 с поиском на каждый язык = поле с языком жизнеспособен? ЧЯДНТ?

создать код на сохранение, который сам распихает поля по докам
т.е. редактируем в одном доке, а оно само дальше
при открытии поле с доп. языками поднимаем из др. языковых доков, но SaveOnDisk=False

 

[rinsk]

Имхо тут нужно ответить на вопрос - а переведенный на другой язык текст нужен только для поиска или же оно будет являться самостоятельным объектом?
Если для поиска - то имхо можно сделать 1 форму с полями типа ref_id, ref_field, lang и заполнять эти переводные документы.
т е они будут как бы ответными к основному. и да - на форме в этом случае можно даже подменять оригинальный текс на переведенный, если он есть конечно...

 

[rinsk]

Имхо тут нужно ответить на вопрос - а переведенный на другой язык текст нужен только для поиска или же оно будет являться самостоятельным объектом?
Если для поиска - то имхо можно сделать 1 форму с полями типа ref_id, ref_field, lang и заполнять эти переводные документы.
т е они будут как бы ответными к основному. и да - на форме в этом случае можно даже подменять оригинальный текс на переведенный, если он есть конечно...

+ вырожденный случай - хранить данные , которые могут иметь варианты переводов в отдельных доках.
В вебе это все делается легко)) На счет клиента... а нафига он вообще нужен ?

 

[NetWood]

Имхо тут нужно ответить на вопрос - а переведенный на другой язык текст нужен только для поиска или же оно будет являться самостоятельным объектом?
Если для поиска - то имхо можно сделать 1 форму с полями типа ref_id, ref_field, lang и заполнять эти переводные документы.
т е они будут как бы ответными к основному. и да - на форме в этом случае можно даже подменять оригинальный текс на переведенный, если он есть конечно...

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

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

 

[NetWood]

+ вырожденный случай - хранить данные , которые могут иметь варианты переводов в отдельных доках.
В вебе это все делается легко)) На счет клиента... а нафига он вообще нужен ?

Так сейчас и есть. Но писать на вебе языковую панель отдельно - грусть печаль. Оно и так есть с редактированием паттернов в юзеркабинете на netwood.org, но еще языки туда - omg. Хотя...

 

[rinsk]

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

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

Но кроме поиска по вьюхе есть еще DQL\Search .
имхо на вьюхах делать такую замороченную схему еще больший гемор.
Если языков 2-3-4 (Основные европейские) - то можно конечно и на 1 форме с полями, а если казахский\вьетнамский - то ой )))

 

[NetWood]

Но кроме поиска по вьюхе есть еще DQL\Search .
имхо на вьюхах делать такую замороченную схему еще больший гемор.
Если языков 2-3-4 (Основные европейские) - то можно конечно и на 1 форме с полями, а если казахский\вьетнамский - то ой )))

Пойду я еще HCL iNotes Redirect iwaredir.ntf поизучаю. Вот там с языками ого-го накручено.