Реализация мультиязычности на сайте

Ответ простой, скука. Все пытаюсь выжать из него хоть что-то дельное.

Это как раз не самое страшное. Хуже что и ума для того чтобы его сделать у него тоже не сильно много.

Неужели это тот самый легендарный Арбайтен? Да, не, фотка слишком брутальная для него 😋

Честно не знаю, но по бесполезным советам очень похож. 

{
    "en": {
        "subjects": {
            "subjects": {
                "chemistry": "chemistry",
                "math": "mathematics"
            }
        },
        "mentors": "mentors",
        "scheduler": "scheduler",
        "news": "news",
        "adverts": "adverts"
    },
    "ru": {
        "subjects": {
            "предметы": {
                "chemistry": "химия",
                "math": "математика"
            }
        },
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления"
    }
}

И отдельный метод соберет не просто перевод, а из ключей второго уровня создаст меню сразу с переводом. Также добавил уровнеь вложености.  Пока только один, но ничего не мешает сделать их сколько угодно. 
Если из этого вырастет коммерческий проект - редактирование  меню будет проходить в админке, не нужно будет руками править что-то в json-е, при этом будет сразу валидироватся правильность добавления данных. И скорее всего подключу тут уже AI - отдаешь ему структуру  меню  и язык и он сам собирает переводы. 

PS. Отстаньте уже от Arbneta,  он в очередной раз показал что ничего из себя не представляет, не вижу смысла загаживать техническую тему  

На сервере всё хранится в файлах на диске или в оперативной памяти. В том числе и БД. Но БД специально оптимизирована именно для работы с данными. Поэтому где "быстрее" - большой вопрос. Зависит от структуры данных и их объёма.

В файлах json можно вообще хранить все данные, полностью отказавшись от SQL-БД. Ещё в xml можно, там иногда даже удобнее. Но если уж ты используешь в проекте мускуль или постгрес, то нафига городить json? Полагаю, это неправильно. Для реализации мультиязычности правильнее использовать те же базы данных.

Это совсем другой человек.

Вы хотите сказать что обращение к базе данных будет быстрее, чем считать файл? (не учитывая использования опкэш и мемкэш)

Здесь же речь шла о словах из интерфейса, а не контента. Контент в базе хранится. А зачем мне для текста из интерфейса (при мультиязычности) хранить его в базе данных, если это изредка только меняется? Подключил файл с нужным языком и сразу используй (json или просто обычный массив в php файле).

вот здесь разница существенная, обычно везде уже включен opcache, поэтому там где он включен, то быстрее будет хранение в пхп файлах, сам так храню, а json требует постоянного парсинга каждый раз

В каких-то случаях и быстрее. Иначе зачем надо было бы придумывать базы данных?

Контент тоже может только изредка меняться. Так что пожалуйста: поналепил кучу файлов с контентом - и в путь, никто не мешает. Просто это принципиально разные подходы, и без разницы, контент это или ваши "интерфейсы".