каждого продукта обязательно есть перевод. Мне сказали, что лучше всего разбить продукты на products и products_ru. Вопрос: так ли это? И если так, то могу ли я "синхронизировать" таблицы, чтобы один и тот же id указывал на один и тот же товар, но в разных переводах?
у фреймворка laravel есть либа, которая вставляет вместо текста json с переводами вроде: {"ru":"Книга", "en":"Book"} и вытаскивает текущий язык и сваливается в fallback, если перевода такого нет
Как называется?
Или делай json и таблицу product_translate или лучше product_content. Потому как сегодня нужно имя продукта перевести, а завтра добавить описание и ещё дополнительные поля на разных языках.
Лучше просто 2 копии приложения под каждый язык с одтельными базами данных. Можно будет поближе к пользователям поставить и нагрузка делиться будет органически
Ты предлагаешь иметь два мастера и сохранять сервисы в две базы? Тойсть продублировать базы ради одной таблицы и одного джойна по языку?
Предложил строить мультиязычные приложения путем создания разных копий с одной кодовой базой. Про одну таблицу информации не было. А так по опыту приложению становится фигово когда все языки туда ломятся и куча костылей напихивается. Но обычно начинается с одной таблички а потом мы хотим тут и там и начинается обрастание костылями по образу и подобию
Там было про продукты. Например продукт Сникерс и описание 2 языка сейчас. Ты сказал по ближе к пользователям. К примеру, в Израиле пять основных распространенных языков на одном клочке земли. Физически от всех основой дата центр на расстоянии 50км. Ближе некуда. Есть ещё вариант - отдать Гугл переводу на автоматический перевод контента и интерфейса (прямо в приложении), если его не существует на нужном языке. В большинстве случаев справляется корректно, нет проблем перевести пиццу и ее инградиенты.
Обсуждают сегодня