За последние 24 часа нас посетили 9310 программистов и 668 роботов. Сейчас ищет 151 программист ...

Мультиязычный сайт / Схема / Избитая тема)

Тема в разделе "MySQL", создана пользователем виталий032, 16 янв 2019.

  1. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    165
    Симпатии:
    26
    Адрес:
    Владивосток
    Еще сегодня утром была такая схема БД (фото ниже):
    [​IMG]
    Дошел до создания панели управления. Обнаружил проблему.
    1. Чтобы добавить предмет, нужно ввести все его переводы.
    2. Если ввести не все переводы, то для того, чтобы найти предмет и добавить его перевод на другом языке НЕОБХОДИМО знать название предмета на любом том языке, перевод которого уже добавлен и соединен с предметом (а-ля, угадайка, добавили ли этот предмет на другом языке, перелопатить переводчик, если языков больше 10)

    У меня стоит поддержка РУССКОГО и АНГЛИЙСКОГО. Но кто его знает сколько языков университет будет в будущем поддерживать (псс, это просто проект ради портфолио).

    Так вот я представляю так, что есть отдельные менеджеры по каждому языку. И, каждый составляет свою языковую версию расписания. (Этот вариант мне меньше нравится, как разработчику, но как менеджеру - больше). При этом, если один менеджер "накосячит", то на расписания других локализаций это не распространится. Фото схемы:
    [​IMG]

    Как лучше?
     
  2. Valick

    Valick Новичок

    С нами с:
    12 авг 2018
    Сообщения:
    846
    Симпатии:
    144
    @виталий032, тут вообще вариантов нет, тут единственное решение. Должен быть один основной язык, без которого невозможно добавление в БД и только он может присваивать идентификатор. Все остальные переводы. В противном случае о целостности данных можно забыть. И в один "прекрасный" день огрести нехилую такую оплеуху от БД.
     
    виталий032 нравится это.
  3. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    165
    Симпатии:
    26
    Адрес:
    Владивосток
    Тогда оставлю первую схему, и добавлю допустим в таблице `subjects` (самая нижняя, посередине) поле `key_title`.

    Чтобы добавить перевод, менеджер обязан знать английский перевод предмета (т.е. `key_title`), например, 'math' - математика.
    -----

    1. Находим в таблице `subjects` запись с 'math'.
    2. Находим в таблице `subject_translations` запись с `subject_id` равным тому, что нашли в предыдущем шаге, и `locale_id` равным id того языка, на котором хочет менеджер добавить перевод.
    3.1 Если такого перевода нет, то показываем ему input для ввода.
    3.2 Если есть, то предлагаем изменить перевод
     
    #3 виталий032, 16 янв 2019
    Последнее редактирование: 16 янв 2019
  4. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    165
    Симпатии:
    26
    Адрес:
    Владивосток
    Вот так сделал:
    - добавил уникальное поле `name` (английские названия будут хранится) для таблиц subjects, school, major, group
    - для преподавателей `teachers` добавил уникальные поля key_firstname, key_lastname и key_middlename
    [​IMG]
     
  5. Valick

    Valick Новичок

    С нами с:
    12 авг 2018
    Сообщения:
    846
    Симпатии:
    144
    не нравится users и teachers
     
    виталий032 нравится это.
  6. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    9.194
    Симпатии:
    687
    Адрес:
    из России с любовью
    @виталий032 просто поинтересуюсь: а почему ты решил хранить переводы в базе? чем не устроил какой-нибудь аналог gettext (как это обычно делается)?
     
  7. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    9.194
    Симпатии:
    687
    Адрес:
    из России с любовью
    ФИО это особый случай. У человека НЕ может быть несколько вариантов для каждого языка: английское + французское + венгерское. Есть его кириллическое написание и есть стандартное написание латиницей (из заграна). Если это иностранец, то кириллическое можно взять из визы, латиницу из паспорта. Когда всего два варианта, логично реализовать через дополнительные поля, а не джойном с другой таблицей.

    В локализации есть такая проблема как многовариантность перевода одного слова или фразы в завивимости от контекста. В геттексте это решается указанием "домена", а с таблицами это будет новый виток усложнения схемы.

    Это всё к тому, что дополнительные таблицы и связи усложняют работу. Когда можно сделать просто, когда ты сам выбираешь решение с нуля, надо делать просто, я считаю.
     
    виталий032 нравится это.
  8. Valick

    Valick Новичок

    С нами с:
    12 авг 2018
    Сообщения:
    846
    Симпатии:
    144
    А если я хочу на одной странице своё фио на всех языках включая китайский арабский и еще хз какой? какой домен надо будет указать?
    Локализация приложения и локализация контента, на мой взгляд разные понятия.
     
    виталий032 и Sail нравится это.
  9. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    9.194
    Симпатии:
    687
    Адрес:
    из России с любовью
    Имена и домен геттекст это разные кейсы. Не уверен, что кто-то пишет русское имя китайскими иероглифами.
    --- Добавлено ---
    Домены это когда "Войти" ты можешь перевести как "Login" и как "Please sign in" и как "Enter" в зависимости от контекста.
    --- Добавлено ---
    В терминах локализации контекст называют доменом. http://php.net/manual/ru/function.gettext
    --- Добавлено ---
    Об именах я написал, т.к. считаю это особым случаем, не укладывающимся в стандартную локализацию. Поэтому вероятно надо хранить имена собственные (не только имена людей) в редактируемой базе. А прочий интерфейс укладывыется в файлы.
     
    виталий032 нравится это.
  10. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    165
    Симпатии:
    26
    Адрес:
    Владивосток
    - в расписании указываю user_id вместо teacher_id
    - добавил роль TEACHER [ INSERT INTO roles VALUES (4, 'teacher') ]
    [​IMG]

    О gettext я не знал. У меня есть нативная поддержка интернационализации в фреймворке.
    В файлах хранятся не изменяемые данные: файл с РУССКИМИ_СЛОВАМИ и АНГЛИЙСКИМИ_СЛОВАМИ

    Переводы в базе, так как с базой проще работать, хотя ... я об этом даже не думал. Статика отдельно, динамика отдельно. Сервер и скомпилированные классы сайта находятся в одном запускаемом jar архиве.

    --
    А что если мы будем искать по переводу? В файле искать будет неудобно.

    Скорее всего так никто не делает. Каждый захочет видеть имя на своем родном языке и на английском.