Какие сущности переводить, а какие — нет с сохранением в таблицу?

Есть таблица, которая хранит категории оценивания:

rateCategory
id_category | name
1                  Вкус
2                  Цвет
3                  Качество

Стоит вопрос о переводе этих слов на другие языки для клиента.

Есть ли смысл создавать отдельную таблицу с переводам:

rateCategoryTranslations
id | lang | name | id_category

Или лучше вынести эти переводы в словарь на клиенте?
Похожих таблиц очень много - требующих переводом. Не могу определиться - как лучше поступить.
  • Вопрос задан
  • 86 просмотров
Решения вопроса 1
@Myclass
Вы все слова или тексты всё равно не сможете содержать в базе. Причин много. Одно из них - поддержка и новшества в программе будут быстрее создаваться, чем уход за таблицей с переводами. Потом - всевозможные тексты ошибок, даже тогда, когда нет соединения с базой данных. Постом - мир давно понял, что переводятся не только тексты, но и картинки, иконки или звуки. Для этого есть в редакторах программ свои инструменты. Потом не только это поле и только эта таблица будет переведена, а и куча других полей и других таблиц

Поэтому на вашем месте для слов или текстов, которые могут быть переведены и находятся в базе, я предложил-бы след. варианты

1.на месте слов или тексов будут писаться или сами тексты или например номера или key для последующего поиска в словаре. Т.е. поле считывается из базы, проверяется, есть-ли перевод для этого key, если - да, то используется перевод для определёмнного языка. Нет, ну тогда выдаётся то, что имеется. Из плюсов - В базе данных не надо ничего менять, только в приложении. Минус - иногда потом стоят в базе слова или значения, с которыми на уровне SQL-запросов ничего не возможно сделать.

2. в принципе как и первый вариант, но key не заменяет текст, а само поле превращается в комбинацию из значения и например через како-то набор символов в key, типа значение{key=xxx}. Из плюсов, как и в первом случае. Из минусов - значения в таблицах становятся не тем, для чего они были предусмотрены.

и 1-й и 2-й варианты мне не нравятся, потому что они совмещают в себе то, что не надо - Значения в базе и перевод для клиента. Поэтому предложу 3-й вариант.

3. дополнительно к полям, которые содержат слова или тексты, которые в последствии могут быть переведены - добавить ещё одно, которое содержит key для перевода и для каждого поля со словами для перевода. Т.е. если поле с key пустое, то на стороне клиента ничего не переводится. Если есть что-то, то по крайней мере идёт поиск в словаре.

Есть-ли перевод для этого key в словаре и как это организовать - это уже отдельный разговор. Тут как я и сказал можно инструментами редакторов работать, можно и таблицы в базе держать - всё зависит от желания и возможностей - всё это редактировать. Ну и не забывать моё первое замечание, когда App стартует, а соединение к базе невозможно сделать. Но это иногда один из тривиальных случаев, который не обязательно за основу брать.

А что я-бы не делал:
- во-первых для одного поля в базе словарь я не писал-бы. Приходит второе поле и что? Ни id не подойдёт или надо дополнительно писать, какая таблица итд.

- также я не писал-бы в одну и ту-же таблицу различные records, но выражающие одно и то-же, но на разных языках. И не важно с одинаковым id или с разным. Язык в клиенте - это язык. С данными продуктов, покупками итд. язык для показа текста ничего общего не имеет.

Надюсь, какая-нибудь из этих мыслей подойдёт.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@Akina
Сетевой и системный админ, SQL-программист.
Количество категорий весьма ограничено. Я бы вообще все положил в одну таблицу:
CREATE TABLE rateCategory (
    category_group INT NOT NULL,    -- группа (категория того-сего) (возможно, также FK)
    category_id INT NOT NULL NOT NULL,  -- идентификатор категории в группе
    category_name_language CHAR(5) NOT NULL,    -- язык наименования (возможно, INT и FK)
    category_name VARCHAR(255) NOT NULL,   -- наименование категории на указанном языке
    PRIMARY KEY (category_group, category_id, category_name_language)
);


Впрочем, на одной таблицы под всё не настаиваю...

Такая структура также позволяет задать и приоритет языков - если перевод на требуемый язык отсутствует, используется вариант на дефолтном языке. Причём приоритет можно задавать общий, для группы, и даже для отдельного термина.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы