Модель базы данных для модуля многоязыкового перевода

0

Мне нужно создать модель 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, есть ли у вас представление о имени таблицы, в котором будут храниться все переведенные слова/фразы? :)

Изменение: похоже, но не дубликат. Связанный вопрос связан с переводом динамических продуктов и наличием отдельной таблицы для каждого переведенного типа. Я говорю о переводе всего содержимого страницы, включая группы в одной таблице.

Теги:
database

2 ответа

1
Лучший ответ

Я не понимаю столбец order lang_entity, но тогда мне, вероятно, это не нужно.

Настройка выглядит разумно, но убедитесь, что вы добавили ограничения внешнего ключа от lang_entity_translation к language и lang_entity.

Что касается имен, я бы назвал таблицу phrase или translatable.

  • 0
    Это был немного плохой пример, потому что у меня было 0,1,2,3 друг за другом. Но дело в том, что каждая группа имеет свой собственный порядок, поэтому она дает пользователю возможность редактировать ее или добавлять что-то посередине. Например, значения группы colorSelect войдут в выпадающее поле выбора, а порядок определяет их порядок в этом поле. Если элемент не входит в группу, он имеет либо значение emtpy, либо значение 0, как у первого.
  • 0
    Что касается именования, мне нравится слово переводимое, которое вы предложили вместо lang_entity. Но вы бы назвали lang_entity_translation просто переводом или переводом_трансляцией? Я склоняюсь к тому, чтобы просто назвать их переводимыми и переводить.
Показать ещё 1 комментарий
1

У нас была схожая ситуация. Это было 7 лет назад. У нас была другая колонка для разных языков. Как и для имени, у нас были Name_Eng, Name_Ger, Name_Spa. У нас было 7-10 языков.

У нас был общий идентификатор для имени для всего языка.

Основываясь на выборе языка из пользовательского интерфейса, мы передали код языка в конец записи. В сохраненном процессе он был добавлен к примеру столбца "Пример", мы будем передавать "Eng", если выбран английский, и мы формируем имя столбца как Name_Eng и получаем данные. мы использовали динамический запрос.

  • 1
    Я не думаю, что это умный дизайн. Вы применяете динамический SQL там, где его можно избежать. Вы должны изменять структуру таблицы каждый раз, когда добавляете / удаляете новый язык.
  • 0
    Я думаю, что это приемлемое решение, если у вас есть набор языков, которые вы можете гарантировать, никогда не изменится. Но для меня пользователи смогут добавлять / удалять языки, чтобы они не работали.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню