собираемся написать плагин для wiki -> и отделить тем самым писателей и разработчиков в проекте.
где же лучше хранить интернационализацию?

1). мне очень нравится подход GWT: при компиляции, проверять, соответствует ли интерфейс файлу properties ( это значит, всё будет на 100% точно собрано ). однако такой способ ведёт за собой слишком много генерированного кода + постоянные изменения в svn.
2). бд мне кажется более флексибильной, однако тут неплохо было бы проверять, всё ли содержится и т.д. и т.п.

а вы что думаете по этому поводу? может быть есть уже готовые решения?

  

Эти строки должны быть доступны на самом начальном этапе работы приложения, поэтому СУБД как их хранилище не подходит.

посему?   

пы.сы: речь идёт об интернационализированных интернетстраницах.

Когда не удастся коммуникация с СУБД, вы на каком языке будете информацию об ошибке выводить? И, возможно, просить отправить feedback администратору?

ты когда-нибудь показывал в вебе ошибку, извините не достучаться к базе данных?

речь идёт не об этом.. описание ошибок - это совсем другая тема.. речь идёт обо всём остальном тексте   

А что, есть варианты?

http://forum.vingrad.ru/index.php?forums=1...ords=scenegraph

млин.. меня что-то ты поражаешь..    вот ты так уверен в своём варианте, теперь объясни мне как ты собираешься в *.property содержать страницы текста в .html формате величиной в несколько строк?? тебе никогда не приходила в голову идея, что неплохо было бы и просмотреть написанный текст? >> и что постоянно deploy-ить приложение? а если приложение деплоится минуты две? что и так сойдёт, типа, авось хорошо будет?    

Platon, 

читайте на два сообщения выше нижнюю строчку, после вашего сообщения.. 

Во-первых, я не собираюсь в файлах *.properties держать html. Во-вторых, для просмотра сгенерированной по шаблону с заданной локалью страницы не нужно ни развертывание приложения на сервере, ни сервер вообще.


polosatij, ваше приложение предполагает расширение с помощью cms?

Добавлено через 2 минуты и 22 секунды

polosatij, если вы заметили только сообщение об ошибке, поясняю: помимо данных, вынутых из БД, обычно существует ещё куча статического контента, который будет всегда недоступен при отсутствии соединения с СУБД.

если ты посмотришь GWT, то он очень часто содержит html внутри *.properties



речь не идёт о чистых .html.. возьмём, например, .xhtml или .jsf, так понятнее будет?   



НЕТ.. однако CMS хотим построить на WIKI, как написано выше.. итого будет два приложения отдельных, но зависисимых друг от друга..
садим писателя, и он пишет текст в wiki, этот текст должен быть перенят порталом..



соединение с СУБД - такого вообще быть не должно, что у тебя БД не работает. как ты можешь подумать тока об этом? весь сервер сразу down. СУБД - это одна из .. этого портала, как и почти любого другого..

а если ты приймешь во внимание тот факт, что всё же в *.properties долженy быть html-теги?

Добавлено через 1 минуту и 57 секунд

первая строчка:



Добавлено через 5 минут и 45 секунд


и ещё.. как ты представляешь себе посадить какую-нибудь девочку журналистку и заставить её искать *.properties файлы в системе и переправлять их?

Если они садятся голой задницей на сковороду, то я должен это воспринимать как руководство к действию?


А при чём тут формат? Разве строку вроде "${name.name}" среди html-тэгов отыскать невозможно?


То есть динамики нет, и страниц, созданных пользователями, интернационализация не касается?


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


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

ты говорил про статичный .html.
строка ${name.name} замепована у тебя куда? на *.properties или на BD? следуя твоей логике - в *.properties.
посмотри, плз, посл вопрос мой   



я не знаю как у тебя, но вот у меня есть нет СУБД, то и сервера тоже нет, потому как в СУБД вся инфа забита интересующая юзера.. падения вообще не должно быть.. или, если оно и будет на одной машине, др. должна перенять работу..



постановка задачи вверху - в самом первом написанном мной сообщении.. 

Ну, на вопрос вверху я давно уже ответил