Как организовать хранение локализованных версий документа в Mongo?
Возник такой интересный вопрос. В приложении может быть несколько языков (>2). Есть коллекция статей (articles). На клиенте, при открытии статьи, нужно отображать список переводов данной статьи. При этом, само приложение может быть на любом языке. То есть, моя ситуация немного отличается от более "стандартной", когда при смене языка сайта просто меняется текст статьи (который можно хранить в другом поле документа, например, article.en_title, article.en_content, article.ru_title и т.д.). В моём случае, ссылка на перевод означает ссылка на другую запись из той же коллекции.
Сложность в том, что когда я указываю что "Article A" имеет английскую версию "Article B", "Article B" должен узнать, что он является переводом "Article A" и точно так же отобразить её в списке переводов на своей странице. Это всё можно делать руками в контроллере, но, кажется, что должно быть более простое и надежное архитектурное решение данного вопроса.
Одним из вариантов была попытка добавить новую коллекцию "translations", но поддерживать её в актуальном виде это тоже отдельный геморрой и добавленная архитектурная сложность.
Поясню сразу. почему вообще возникла необходимость так сделать. В "классическом" варианте, автор статьи обычно может сразу же в свою статью добавить переводы, которые бы хранились в соответствующих полях одного документа. Изи фича, пуш в мастер. Однако, если на платформе есть множество авторов и множество языков и, если автор 2 решил перевести статью автора 1, то "классический" вариант не подходит, т.к. подразумевает возможность редактирования оригинальной записи. Поэтому в каждой статье должна быть возможность для перевода другим автором, но это должна быть совершенно другая запись в коллекции, и обе записи должны каким-то образом синхронизироваться и знать друг о друге. Т.к. могут добавляться последующие переводы на другие языки, плюс какие-то из вариантов могут быть удалены и т.д.
Тег монга потому что делаю на монге и решение для неё явно будет отличаться от решения аналогичной проблемы в реляционных базах.
Простой
