Добрый день! В первую очередь хотелось бы сказать спасибо за такой развернутый отзыв ?
Теперь попробую ответить/прокомментировать по пунктам.
Back-end:
Было несколько вариантов того, как реализовать работу с переводами. Тот, на котором мы остановились, предполагал изменение всех сериализаторов (как раз добавление полей с переводами в Meta.fields), и это было решено сделать с помощью миксина, т.к. требовало только добавление нового родителя.
Предложение закешировать хорошее, уже добавил 3 строки в миксин и время второй и следующих сериализаций уменьшилось с 0.1 до 0.01 сек. ??
Если язык удалён - скорее всего это обдуманный шаг. Про медленных переводчиков: и в modeltranslation и в django-tof есть fallback языки, которые как раз и нужны для того, чтобы определить список запасных языков, если на выбранный язык перевода нет. Во-вторых, есть вариант программно ограничить список языков с которыми могут работать пользователи, до тех пор пока переводы не будут добавлены.
У ModelTranslation есть косяки, но есть и плюсы - отсутствие дополнительных запросов в БД. Насколько я понял вы имеете ввиду слишком большую таблицу (10 полей х 10 переводов - уже минимум 110 полей в таблице), но тут уже вопрос не к ModelTranslation, а к выбору технологий - зачем начинать использовать ModelTranslation на проекте с таким большим количеством языков.
У вашего решения тоже есть минусы, как автор вы это знаете. К тому же репозиторий не обновляется уже около 4-х лет. Возможно в какой-то момент вы столкнулись с проблемой, которую сложно решить (возможно плотная интеграция в ORM)? В любом случае - спасибо, это ещё один вариант, который стоит рассмотреть.
Front-End:
Крайне не понял про "лютый хардкод" в моделях. Всё что происходит - наследование и указание списка полей. Во-вторых - класс TranslatableModel делает чуть больше, чем ваш пример. Ваш пример очень упрощен, в нём описан только getter свойств (причем для каждого свойства будет сначала выполнена проверка наличия атрибута с названием <название_свойства>_<язык>), и если расширить этот пример до класса, который будет +- с таким же функционалом - я не думаю, что он будет намного меньше.
Хорошее предложение, к тому же и реализуется очень просто. Спасибо ??
Я с вами полностью согласен, была бы моя воля - я бы вообще запретил переводы для динамических данных. С другой стороны есть ТЗ со своими требованиями. Отправка данных на всех языках обусловлена к тому же тем, как мы работаем с данными - после того как сервере произошло событие (например создание объекта в БД) нам необходимо отправить этот объект всем подключенным пользователям по WS, и этот новый объект должен появится у пользователя на том языке, который у него активирован.
Эта обертка нужна только для того, чтобы можно было перейти в метод getField и посмотреть на комментарий, который у него написан. Это лучший вариант, чем писать в каждой конкретной модели что значит this.name = data; this.desc = data и почему каждому свойству присваивается data, когда data - это все данные объекта.
На самом деле у нас несколько проектов, которые используют описаный подход (в проектах > 10 моделей с переводами и > 20 переводимых полей) и нет никаких проблем в работе с переводами. После реализации этого кода добавление новых сущностей с переводами не доставляет проблем - нужно просто добавить миксин в сериализатор и в класс модели на фронте, а всё остальное уже работает. Именно из-за простоты реализации и использования захотелось поделиться тем, что получилось.
В любом случае - нет единого подхода для решения похожей задачи в разных проектах, и нужно понимать куда движется проект и как он будет развиваться чтобы принимать решение об использовании нашего подхода или какого-либо другого.
Добрый день! В первую очередь хотелось бы сказать спасибо за такой развернутый отзыв ?
Теперь попробую ответить/прокомментировать по пунктам.
Back-end:
Было несколько вариантов того, как реализовать работу с переводами. Тот, на котором мы остановились, предполагал изменение всех сериализаторов (как раз добавление полей с переводами в
Meta.fields), и это было решено сделать с помощью миксина, т.к. требовало только добавление нового родителя.Предложение закешировать хорошее, уже добавил 3 строки в миксин и время второй и следующих сериализаций уменьшилось с 0.1 до 0.01 сек. ??
Если язык удалён - скорее всего это обдуманный шаг. Про медленных переводчиков: и в
modeltranslationи вdjango-tofесть fallback языки, которые как раз и нужны для того, чтобы определить список запасных языков, если на выбранный язык перевода нет. Во-вторых, есть вариант программно ограничить список языков с которыми могут работать пользователи, до тех пор пока переводы не будут добавлены.У
ModelTranslationесть косяки, но есть и плюсы - отсутствие дополнительных запросов в БД. Насколько я понял вы имеете ввиду слишком большую таблицу (10 полей х 10 переводов - уже минимум 110 полей в таблице), но тут уже вопрос не кModelTranslation, а к выбору технологий - зачем начинать использоватьModelTranslationна проекте с таким большим количеством языков.У вашего решения тоже есть минусы, как автор вы это знаете. К тому же репозиторий не обновляется уже около 4-х лет. Возможно в какой-то момент вы столкнулись с проблемой, которую сложно решить (возможно плотная интеграция в ORM)? В любом случае - спасибо, это ещё один вариант, который стоит рассмотреть.
Front-End:
Крайне не понял про "лютый хардкод" в моделях. Всё что происходит - наследование и указание списка полей. Во-вторых - класс
TranslatableModelделает чуть больше, чем ваш пример. Ваш пример очень упрощен, в нём описан только getter свойств (причем для каждого свойства будет сначала выполнена проверка наличия атрибута с названием <название_свойства>_<язык>), и если расширить этот пример до класса, который будет +- с таким же функционалом - я не думаю, что он будет намного меньше.Хорошее предложение, к тому же и реализуется очень просто. Спасибо ??
Я с вами полностью согласен, была бы моя воля - я бы вообще запретил переводы для динамических данных. С другой стороны есть ТЗ со своими требованиями. Отправка данных на всех языках обусловлена к тому же тем, как мы работаем с данными - после того как сервере произошло событие (например создание объекта в БД) нам необходимо отправить этот объект всем подключенным пользователям по WS, и этот новый объект должен появится у пользователя на том языке, который у него активирован.
Эта обертка нужна только для того, чтобы можно было перейти в метод
getFieldи посмотреть на комментарий, который у него написан. Это лучший вариант, чем писать в каждой конкретной модели что значитthis.name = data; this.desc = dataи почему каждому свойству присваивается data, когда data - это все данные объекта.На самом деле у нас несколько проектов, которые используют описаный подход (в проектах > 10 моделей с переводами и > 20 переводимых полей) и нет никаких проблем в работе с переводами. После реализации этого кода добавление новых сущностей с переводами не доставляет проблем - нужно просто добавить миксин в сериализатор и в класс модели на фронте, а всё остальное уже работает. Именно из-за простоты реализации и использования захотелось поделиться тем, что получилось.
В любом случае - нет единого подхода для решения похожей задачи в разных проектах, и нужно понимать куда движется проект и как он будет развиваться чтобы принимать решение об использовании нашего подхода или какого-либо другого.