kfuntov

Переопределением CMessageSource::loadMessages можно сделать всё что угодно.
Например в одном проекте не использовались категории, но в зависимости от текущего параметра в Request надо было по-разному переводить одни и те же слова (в рамках одного и того же языка) (вроде как у Вас похожая проблема). Так вот там был примерно такой код:

<?php
class MessageSource extends CMessageSource
{
    protected function loadMessages($category, $language)
    {
        $config = require(Yii::getPathOfAlias('application.messages') . '/' . $language . '/default.php');

        $childConfig = Yii::getPathOfAlias('application.messages') . '/' . $language . '/children/' . Yii::app()->request->getChildrenTranslateId() . '.php';
        if (file_exists($childConfig)) {
            $vocab = require($childConfig);
            if (is_array($vocab)) {
                $config = array_merge($config, $vocab);
            }
        }

        return $config;
    }
}

Таким образом порядок перевода в функции t был такой - сначала ищем в дочернем словеаре, если нет там - ищем в дефолтном для языка.
Если нужно использовать категории - можно соответствующим образом изменить метод loadMessages.
Основная идея этого метода в любом случае будет в том, что array_merge перезаписывает значения, если ключи одинаковые. Таким образом можно сделать как бы наследование файлов с сообщениями.

Более-менее распространённых реляционных баз данных сейчас не так много:
Oracle DB и Microsoft SQL Server - точно не подходят под "простые". Это большие enterprise решения, на обучение которым люди тратят уйму времени.

SQLite - Вы просили не писать (хотя под определение "простая, логичная и понятная" подходит как нельзя лучше: нету пользователей и ещё части усложняющей функциональности, при этом достаточно неплохо выдерживает SQL стандарт)

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

PostgreSQL - сама по себе логичная и приятная, но далеко не простая. Функциональности очень много, причём много сложной.

Тут есть неплохое "сравнение" (скорее описание общих отличий) SQLite MySQL и PostgreSQL.

Про менее распространённые:
Не очень понятно, что вообще надо. Вопрос очень абстрактный. Если надо не только простую, понятную и логичную, а ещё, чтобы разобраться можно было, то надо, чтобы было хоть сколько-то материала (ответов на вопросы, примеров, туториалов).
Вот страница русской вики (в списке не только реляционные, их пропускал)
Посмотрим на те, у которых есть хотя бы страничка в русской wiki. (Если нет даже страницы, то вряд ли на русско-язычном ресурсе эту бд кому-нибудь посоветуют). Заранее прошу прощения за пробегание по верхам (с большинством бд не работал, мог допустить неточности):
* Caché - "позиционирующаяся производителем как «объектно-реляционная» или «постреляционная»" - вряд ли "простая и понятная"
* DB2 и Informix - базы данных, о которых я даже не смог понять, простые они, или нет. Обе - продукты IBM. Может быть она из них - то, что нужно (я правда не разобрался).
* Ingres - предшественник PostgreSQL (не вижу смысла иметь дела с ней, когда есть Postgre)
* mSQL - уже не разрабатывается, была вытеснена MySQL
* Btrieve - уже не разрабатывается
* ЛИНТЕР - уже не разрабатывается
* Adaptive Server Enterprise - не является бесплатной (дальше лень смотреть, если честно)
* Microsoft Access - комментарии излишни
* OpenOffice Base - думаю, что так же, как и Access - годится для офис-менеджеров
* Rdb - предшественник Interbase, хрен поставишь на ПК
* Interbase - предшественник Firebird
* Firebird - кстати, достаточно известная база данных, вполне может по соперничать с MySQL и пр. После изучения дополнительной информации о ней, может быть даже посоветовал бы её, как не такую сложную, как Postgre, но и не отход от стандартов и кашу MySQL (хотя сам с Firebird не работал, может оно там ещё сложней и замороченей)
* HSQLDB - выглядит как маленькая, лёгкая бд, которая хорошо поддерживает стандарты SQL и всё. То есть вполне подходит под определение простая, но достаточно близка к почему-то заранее отклонённой SQLite

Как итог напишу сложившееся общее субъективное мнение:
Лёгкие и (поэтому) простые - SQLite (проще работать с базой, больше информации), HSQLDB (работает согласно стандартам SQL).
Много информации, много возможностей, логичная - PostgreSQL.
ОЧЕНЬ много информации, достаточно простая, не логичная во многом - MySQL.
Достаточно простая, сравнительно мало информации, достаточно логичная (вообщем везде средняя) - Firebird.

P.S. Пока исследовал интернет совсем забыл про то, что в вопросе было про наличие удобных инструментов. По этому пункту
MySQL получает 5
PostgreSQL - 4
SQLLite - 4
Firebird - 4
HSQLDB - 3

Достаточно распространённое решение - со стороны страницы аяксом (из JS) запрашивать сервер с некоторй переодичностью. Типа "ничего не изменилось?". А на сервере каждый раз отвечать, либо - "не", либо "да, вот это вот". И на JS это обновлять.

www.charlesproxy.com
www.telerik.com/fiddler

SELECT b.*
FROM magazine -brands AS b
INNER JOIN magazine -product_brands AS pb ON pb.brand = b.id
INNER JOIN magazine -product_category AS pc ON pc.product = pb.product
WHERE pc.category = #ID ИСКОМОЙ КАТЕГОРИИ#

Самой правильной(броневой) практикой вроде как считается - создание двух пользователей для проекта: для деплоя и для работы сервера. Помещение их в одну группу.
Выставление прав на большинство (по возможности все) фалы проекта - 644.
Выставление прав на большинство (вот тут скорее всего не все) директории проекта - 755.
Для тех фалов/директорий, куда должен мочь писать сервер (логи, кеш и т.п.) - 664 и 775 соответственно.
Owner у всего, что не создал сервер: пользователь_для_деплоя:общая_группа .

class ReportForm(forms.ModelForm):

    def __init__(self, *args, **kwargs):
        super(ReportForm, self).__init__(*args, **kwargs)
        for key in self.fields.keys():
            self.fields[key].widget = forms.TextInput(attrs={'class': 'form-control'})

    @staticmethod
    def getInstance(name, *args, **kwargs):
         if name == "one":
             return ReportOne(*args, **kwargs)
        else:
            return ReportTwo(*args, **kwargs)

Не уверен в том, что имелось в виду под "по её имени", но теперь можно будет создавать формы так:

newform = ReportForm.getInstance("one")
newform = ReportForm.getInstance("two")

Не существует серебряной пули. Flask - очень гибкий, в нём позволительно делать и так, и так, и так.
Как лучше - зависит от очень большого количества деталей, среди которых есть, например, "а как мы делаем/собираемся делать в остальных проектах?".

Вот, например, достаточно распространённый способ организации директорий https://github.com/sean-/flask-skeleton

Ещё есть вариант все нужные запросы посохранять в хранимые процедуры, и разрешить только их использование.

Для apache в htaccess

RewriteEngine on 
RewriteRule ^(.*)$ http://www.newdomain.com/$1 [R=301,L]

Просто чтение csv быстрее выборки из базы.
+ можно гзиповать раз в неделю csv, которые старше месяца. Это сильно сократит размер.

Скопируй из адресной строки сюда пожалуйста.
Я могу и старый и новый открыть, если хочу:
https://www.google.com/webhp?complete=0#complete=0... - Старый
https://www.google.ru/search?q=asd - Новый