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

Еще, кстати, аргумент пришел в голову. Как исходные данные: речь о php и используем модульность. В случае массива последовательность следующая. Где то в начале инициализируется массив (возможно пустой) скажем $dict. Далее подключается один или множество языковых файлов. Примерно такого содержания

<?php
$dict['key1']='value1';
$dict['key2']='value2';

Т.е. идет просто заполнение массива.

Если же будет храниться в json.  То для каждого файла придется делать (в грубом варианте):

$json = file_get_contents('module_lang.json'); //считали
$moduleTexts = json_decode($json); // преобразовали
$dict = array_merge($dict, $moduleTexts); // объединили с ранее набранным массивом

А на противоположной стороне весов

include_once 'module_lang.php'; 

Обработка ошибок за скобками - т.к. она одинаковая

Довольно странное заявление. Ты когда-нибудь заглядывал в код или в БД популярных CMS? Попробуй заглянуть. У них меню в базе данных. Либо генерится "на лету" в случае динамического контента (но это явно не случай ТС). Никакими файлами там и не пахнет. Правда, есть и исключения - Битрикс, например.
Хранение данных в БД - общепринятая практика. Для того и разрабатывались реляционные базы данных.

Не стоит рассуждать о том, в чем не разбираешься. Приводить в пример то, как построены "популярные ЦМС" - показывать свою ограниченность. Они разработаны для массового пользователя, там цель - не максимальная скорость и гибкость, а дать юзеру с поверхностными знаниями возможность быстренько создать сайтик. Ты хоть раз делал профилирование запросов? Одно дело, когда на сайт заходит 5-10-20 тысяч пользователей почитать новости там пообщаться. И другое дело когда сидят постоянно такое количество и работают плотно с информацией. Все слезы тут на форуме - ой  у меня все тормозит... Мой сервис будет работать на одноядерной машине с гигом оперативы быстрее на порядок, чем тот же вордпресс  на 10-ти ядрах на 8 гигах оперативы при одинаковом количестве пользователей только за счет оптимизации работы с базой и с памятью. Твое мнение неинтересно абсолютно, предпочитаю общение с теми, у кого есть нормальный опыт.

Никогда не пользовался разными CMS и не собираюсь. Зачем мне эти тормознутые монстры, да и все равно пришлось бы дорабатывать под свои проекты.

Еще в 2005 определился со своим движком, 2 или 3 раза переделывал только функциональность за все время (логика оставалась). Что там сложного? 1 исполняемый файл, в базе для каждой страницы подключается шаблон и модули. Исполняемый файл собирает страницу.

И на этом движке были реализованы не только простые сайты, но и каталоги (с личными аккаунтами), сервисы.

Я не против бд для меню, при условии: 1) реализовано полное кэширование страницы; 2) реализовано кеширование через меткешед (чтобы не обращаться к базе данных)

Это просто для примера. У меня, например, много проектов на самописах на базе фреймворка, но в них я тоже использую БД для хранения меню. Это очень удобно, поэтому не вижу смысла делать иначе, исходя из каких-то фееричных представлений. Хотя у меня есть CMS собственной разработки, сделанная исключительно на файлах, вообще без использования реляционных БД.
А популярные CMS я привёл для примера по той причине, что это наглядно показывает, как делают свои проекты общепризнанные грамотные разработчики, а не Вася Пупкин, пилящий свой велосипед.

Перечитай название темы для начала. При чем тут меню? Я тоже когда то в проекте  делал динамическое добавление страниц в меню. Записи с определенным типом, например, категория, автоматически добавлялись в меняю. В этой теме разговор идет о простом и быстром переводе интерфейса, тратить ресурс базы данных на который будет только очень неумелый разработчик. 

Ну я же кроме названия темы прочитал и все сообщения в теме. И там говорится про меню. Или ты забыл?

Это принципиально не отличается от перевода всего остального. В том числе и меню.

У умелых разработчиков есть в основном два подхода к проблеме перевода:
- хранение перевода контента в базе данных
- хранение переведённых фраз в специальных языковых файлах.
Неумелых разработчиков мы здесь не обсуждаем, они могут творить вообще всё, что им в башку взбредёт.

Принимается, если говорить в таком ключе. Но сакцентирую - это не предмет топика. Мне интересен перевод определенного интерфейса, который будет очень редко, практически никогда меняться. Для этого использовать БД нецелесообразно. 

Вы несколько путаете. Меню это скорее не интерфейс, это динамический контент, то чем управляет контент менеджер. А тут речь об интерфейсных фразах

Ларваель , Symfony,  Джанго, вордпресс  и да, Битрикс не исключение -  у него тоже локализация на файлах построена. 

Внимание:  речь о локализации интерфейса, а не контента сайта. Это рядом, но разное