Shitbox2Все хранится в базе потому что там хранится, вообще, все. Т.е. ни в HTML ни в JS никаких текстов, кроме технических нет.
И получаем на свою голову проблемы с хранением версий/истории правок сайта. Базу в систему контроля версий уж очень неудобно уталкивать.

HettОдно дело если локализацией занимается погроммист, он открыл проектик пошаманил там в файлах. А если нужен веб-интерфейс, то вы тут же обретаете дополнительный гемморой.

Мне всегда казалось, что научить локализатора править тексты в файлах ресурсов обычным текстовым редактором гораздо проще, чем Web интерфейс для них делать. А нормальный переводчик, привыкший к текстовым редакторам дурной Web-интерфейс кучу раз проклянет.

Ренатне разу не видел чтобы локализатор имел доступ к ftp или к репозиторию проекта, да и еще умел работать с онными.
А ему не надо уметь. У него есть доступ к текстовому документу ресурсов в google docs или чем-то похожем.

Потом мы его сами на место кладем/тестируем/исправляем ошибки/коммитим.
Говорим, что нас не устроило (прямо в goggle docs комментариями) и цикл повторяется.

HettА за день можно и обвертку написать, где переводчик будет кликать на текст и тут же править его и сохранять.
Без версионности работать с любым текстовым материалом плохо. Очень. А в GoogleDocs она есть. Можно, конечно, и в свою обертку встроить, но стоит ли?

как то так...и какая разница кладёте вы его в БД или файл ресурсов или ещё куда? ;)
всяко, он попадает сперва к вам а уж потом в проект!

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

А если мы перевод сразу в базу данных заливаем, не включая текстовый исходник в проект - то
смотри ниже.
делайте бэкап, что ли... ;)


То-то программисты системы контроля версий придумали.

"Самай последний перевод этой странцы в этом файле лежит, другой - в другом. Как бы нам
теперь как бы нам все эти изменения в один файл слить? А вот тут мы вчера решили измениния отменить, у кого версия за н-ное число сохранилась"

Без системы контроля версий с текстовой информацией работать нельзя. Бардак выходит.

как-то так...м.б. как минимум, целостность информации + тот же бэкап?

Про целостность в смысле "чтобы не хранились переводы для объектов, на которые ссылок нет" - можно согласится.
Про бэкап - не понял. Делать резервное копирование статических файлов гораздо проще, чем базы.

да ладно - делай инсерт в БД с временной меткой вместо апдейта - не мне тебя учить - т.ч. считай, разговор ни о чём!

История изменений переводов на этапе функционирования сайта вещь совершенно не нужная, она нужна большей частью тому, кто сайт делает. Поэтому где-то в движке сайта ей заниматься вредно. Вот если именно CMS пишется - тогда нужно об этом думать.

Твоя позиция ясна - сохранять всё по файликам в фс и дёргать их!

Совершенно верно, подгружается файл ресурсов и используется. Автор темы хочет генерацией страницы на JS заниматься,
те можно брать шаблонный движок на JS и хранить на сервере шаблоны для его работы. Вытянуть же браузером статический файл /templates/i18n/ru.json проще и для головы и для сервера.

Явных преимуществ твоего подхода против хранения информации в БД (для конкретного случая) я не увидел!

Преимущества будут в момент, когда нам потребуется слить изменения от двух разработчиков. Один поправил один раздел сайта, другой человек - другой раздел. Но при этом одну и ту же фразу перевели по разному. Теперь это нужно все слить в одно целое.
При использовании текстовых ресурсов у нас система контроля версий заметит, что одну и ту же строку в файле ресурса меняли оба. А с базой данных нужно будет самому отслеживать.
Да и не основная это проблема - место хранения!

Вопрос был про то, как делать. Я бы дела так:
Для динамического контента (те такой, который пользователи сайта сами без участия программистов добавляют) делаем по таблице на язык и жоиним. Если нравится из отдельных столбцов язык вытаскивать - делам подходящий VIEW.
Для всего остального - ресурсы в виде статических текстовых файлов для понравившегося варианта gettext.

опустим подгрузку json-а - бо это жесть!

Если шаблонизатор у нас работает внутри браузера, а не на серверной стороне - то вполне неплохо. Другое дело, что сама идея шаблонного движка внутри браузера у меня некоторое сомнение вызывает.
интересуют твои действия, в соответствии с твоей парадигмой?
[/quot]
Загрузку ресурсов и шаблонов пропустим. А в самом шаблоне (условный шаблонизатор) странички будет



Шаблонизатор возмет шаблон, возмет ресурсы локализации и через gettext подставит во все _('...') перевод.
Если верстка для разных языков отличается, то тогда придется для разных языков руками разные шаблоны страницы делать.

Если хочется сделать оптимизацию загрузки, жертвуя дисковым пространством, то придется делать скрипт, который на этапе сборки сайта из шаблонов c _('') и ресурсов делает странички с уже подставленным языком. Но это уже если очень надо.

РенатПришли таки к выводу, закроем этот балаган?

Можно закрыть. Просто я как раз занимаюсь поддержкой сайта в архитектуре, которую Shitbox2 хочет использовать, сделан.
Те
1) Статические по смыслу тексты хранятся в базе.
2) Хранятся в колонках с именами *_ru, *_en
3) Страница большей частью генерируется в браузере клинета
4) Шаблонизатор при этом не используется.

Удовольствие, прямо скажем, сильно ниже среднего.

Может, когда-нибудь кто-нибудь прочитает и так делать не будет.