Мне нужно создать модель db для бэкэнд-модуля, где пользователь может переводить содержимое страницы на несколько языков. То, что будет переведено, это основные слова, фразы, имена ссылок, названия, имена полей, значения полей. Они также должны быть сгруппированы, поэтому я могу найти их по имени группы. Например, если есть поле выбора на странице с разными цветами в качестве параметров, тогда я должен иметь возможность выбрать все из них по имени группы.
Итак, вот что я имею на данный момент:
lang
+----+---------+
| id | name |
+----+---------+
| 1 | english |
| 2 | german |
+----+---------+
lang_entity
+----+------------+-------------+-------+-------+
| id | module | group | name | order |
+----+------------+-------------+-------+-------+
| 1 | general | | hello | 0 |
| 2 | accounting | colorSelect | one | 1 |
| 3 | accounting | colorSelect | two | 2 |
| 4 | accounting | colorSelect | three | 3 |
+----+------------+-------------+-------+-------+
lang_entity_translation
+----+---------+----------------+-------------+
| id | lang_id | lang_entity_id | translation |
+----+---------+----------------+-------------+
| 1 | 1 | 1 | Hello |
| 2 | 2 | 1 | Guten tag |
| 3 | 1 | 2 | One |
| 4 | 2 | 2 | Ein |
| 5 | 1 | 3 | Two |
| 6 | 2 | 3 | Zwei |
| 7 | 1 | 4 | Three |
| 8 | 2 | 4 | Drei |
+----+---------+----------------+-------------+
Так что в таблице языков есть разные языки.
В таблице lang_entity есть объекты, которые могут быть переведены для разных языков. Строка модуля состоит в том, чтобы группировать их по модулям страницы в модуле трансляции backend. Кроме того, это дает мне возможность иметь объекты с одинаковым именем для разных модулей. Группа, упомянутая выше, необходима для выбора и, возможно, в некоторых других местах, где будут использоваться несколько значений. Это также дает мне возможность разрешить пользователю добавлять и упорядочивать объекты в одной группе.
И таблица lang_entity_translation содержит переводы для каждого объекта на каждом языке.
Итак, мой вопрос - это видимые недостатки в этом виде дизайна? Не могли бы вы рекомендовать что-то другое?
Также вопрос о бонусе: мне действительно не нравится имя таблицы lang_entity, есть ли у вас представление о имени таблицы, в котором будут храниться все переведенные слова/фразы? :)
Изменение: похоже, но не дубликат. Связанный вопрос связан с переводом динамических продуктов и наличием отдельной таблицы для каждого переведенного типа. Я говорю о переводе всего содержимого страницы, включая группы в одной таблице.
Я не понимаю столбец order
lang_entity
, но тогда мне, вероятно, это не нужно.
Настройка выглядит разумно, но убедитесь, что вы добавили ограничения внешнего ключа от lang_entity_translation
к language
и lang_entity
.
Что касается имен, я бы назвал таблицу phrase
или translatable
.
У нас была схожая ситуация. Это было 7 лет назад. У нас была другая колонка для разных языков. Как и для имени, у нас были Name_Eng, Name_Ger, Name_Spa. У нас было 7-10 языков.
У нас был общий идентификатор для имени для всего языка.
Основываясь на выборе языка из пользовательского интерфейса, мы передали код языка в конец записи. В сохраненном процессе он был добавлен к примеру столбца "Пример", мы будем передавать "Eng", если выбран английский, и мы формируем имя столбца как Name_Eng и получаем данные. мы использовали динамический запрос.