Еще сегодня утром была такая схема БД (фото ниже): Дошел до создания панели управления. Обнаружил проблему. 1. Чтобы добавить предмет, нужно ввести все его переводы. 2. Если ввести не все переводы, то для того, чтобы найти предмет и добавить его перевод на другом языке НЕОБХОДИМО знать название предмета на любом том языке, перевод которого уже добавлен и соединен с предметом (а-ля, угадайка, добавили ли этот предмет на другом языке, перелопатить переводчик, если языков больше 10) У меня стоит поддержка РУССКОГО и АНГЛИЙСКОГО. Но кто его знает сколько языков университет будет в будущем поддерживать (псс, это просто проект ради портфолио). Так вот я представляю так, что есть отдельные менеджеры по каждому языку. И, каждый составляет свою языковую версию расписания. (Этот вариант мне меньше нравится, как разработчику, но как менеджеру - больше). При этом, если один менеджер "накосячит", то на расписания других локализаций это не распространится. Фото схемы: Как лучше?
@виталий032, тут вообще вариантов нет, тут единственное решение. Должен быть один основной язык, без которого невозможно добавление в БД и только он может присваивать идентификатор. Все остальные переводы. В противном случае о целостности данных можно забыть. И в один "прекрасный" день огрести нехилую такую оплеуху от БД.
Тогда оставлю первую схему, и добавлю допустим в таблице `subjects` (самая нижняя, посередине) поле `key_title`. Чтобы добавить перевод, менеджер обязан знать английский перевод предмета (т.е. `key_title`), например, 'math' - математика. ----- 1. Находим в таблице `subjects` запись с 'math'. 2. Находим в таблице `subject_translations` запись с `subject_id` равным тому, что нашли в предыдущем шаге, и `locale_id` равным id того языка, на котором хочет менеджер добавить перевод. 3.1 Если такого перевода нет, то показываем ему input для ввода. 3.2 Если есть, то предлагаем изменить перевод
Вот так сделал: - добавил уникальное поле `name` (английские названия будут хранится) для таблиц subjects, school, major, group - для преподавателей `teachers` добавил уникальные поля key_firstname, key_lastname и key_middlename
@виталий032 просто поинтересуюсь: а почему ты решил хранить переводы в базе? чем не устроил какой-нибудь аналог gettext (как это обычно делается)?
ФИО это особый случай. У человека НЕ может быть несколько вариантов для каждого языка: английское + французское + венгерское. Есть его кириллическое написание и есть стандартное написание латиницей (из заграна). Если это иностранец, то кириллическое можно взять из визы, латиницу из паспорта. Когда всего два варианта, логично реализовать через дополнительные поля, а не джойном с другой таблицей. В локализации есть такая проблема как многовариантность перевода одного слова или фразы в завивимости от контекста. В геттексте это решается указанием "домена", а с таблицами это будет новый виток усложнения схемы. Это всё к тому, что дополнительные таблицы и связи усложняют работу. Когда можно сделать просто, когда ты сам выбираешь решение с нуля, надо делать просто, я считаю.
А если я хочу на одной странице своё фио на всех языках включая китайский арабский и еще хз какой? какой домен надо будет указать? Локализация приложения и локализация контента, на мой взгляд разные понятия.
Имена и домен геттекст это разные кейсы. Не уверен, что кто-то пишет русское имя китайскими иероглифами. --- Добавлено --- Домены это когда "Войти" ты можешь перевести как "Login" и как "Please sign in" и как "Enter" в зависимости от контекста. --- Добавлено --- В терминах локализации контекст называют доменом. http://php.net/manual/ru/function.gettext --- Добавлено --- Об именах я написал, т.к. считаю это особым случаем, не укладывающимся в стандартную локализацию. Поэтому вероятно надо хранить имена собственные (не только имена людей) в редактируемой базе. А прочий интерфейс укладывыется в файлы.
- в расписании указываю user_id вместо teacher_id - добавил роль TEACHER [ INSERT INTO roles VALUES (4, 'teacher') ] О gettext я не знал. У меня есть нативная поддержка интернационализации в фреймворке. В файлах хранятся не изменяемые данные: файл с РУССКИМИ_СЛОВАМИ и АНГЛИЙСКИМИ_СЛОВАМИ Переводы в базе, так как с базой проще работать, хотя ... я об этом даже не думал. Статика отдельно, динамика отдельно. Сервер и скомпилированные классы сайта находятся в одном запускаемом jar архиве. -- А что если мы будем искать по переводу? В файле искать будет неудобно. Скорее всего так никто не делает. Каждый захочет видеть имя на своем родном языке и на английском.