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

Хм. Почему это? Мне кажется тут вообще солид как то с натяжкой к этому вопросу подходит.

У меня есть проект где ежегодно в один прекрасный день могут заходит   140тысяч активных пользователей (и это даже "лайтовый" вариант) в остальное время это сайт с которым справится даже "минимальный тариф любого хостинга". Так вот я как бы посмотрев на то как ведут себя сервера, решил эти интерфейсные тексты выкинуть в файлы. (правда они были в основной бД).  База становится узким горлышком.  А эти языковые фразы - которые безболезненно можно оттуда убрать.    Текст, который, по сути, статика. Меняется, но достаточно редко.   Добавлять еще базу -  а какой смысл? Все равно заметно большая  часть закеширована. Удобство редактирования - это интерфейс, стоит ли его вот так любому "контент менеджеру" править по 100 раз на дню?  Да и скорость доступа на серверных файловых системах  сейчас вполне себе.  (тем более не забываем, что один фиг в бд если грубои  на холодную - это все те же файлы :)

Возможно, я непонятно вычказался. Ключевое слово было в "РАЗНЫХ файлах" и я зацепился не к файлам а что в ДЛЕ для языкового варианта нужно создать разный шаблон и разный языковый файл. А так я уже привел сравнения работы по скорости и простоте с файлами и базой. Почему не SOLID? 
Как работает система шаблонов у меня? Есть базовый шаблон с блоками - header, menu, content, footer.  Это полноценный шаблон страницы. Если мне нужно создать новую страницу, я наследуюсь от базового и добавляю изменения только в тот блок, что необходим. Таким образом у меня всегда один шаблон меню, в который я подгружаю перевод  из файла в зависимости от урл и или каких-то настроек. Это чистый СОЛИД.  Возможно я не так понял идею в ДЛЕ и там реализовано в таком же ключе. Но мне не нужно создавать каждый раз темплэйт под язык, нужно под новый тип страницы. 

Я уже выше обьяснял. Дает возможность гибкого изменения из админки. Для добавления строчки не нужно лезть в код, пересобирать и потом деплоить новую версию. json в коде уже преобразуется в массив( у нас это называется словарь) один раз и дальше используется.

Эх, вот как же ты далек от нормального программирования... С чего ты решил что я мучаюсь - мне это доставляет удовольствие. И вообще-то это уже давно сделано и я даже могу показать, как это работает. Не так как ты - все только на словах, а когда доходит до конкретных вопросов - сливаешься. 
У тебя нет понятий архитектуры и  реализации. Мой вопрос был про архитектуру. И мне было полезно знать как это сделано в вордпрессе, ДЛЕ, какие свои решения люди используют. На этой основе у меня организовался паттерн , который я и написал за полдня. А на архитектуру ушло 3. В этом и разница между нами. Ты копаешься внутри, не продумав паттерны, интерфейсы и городишь велосипед. потому что когда сидишь внутри клубка, сложно его распутать.
Мне абсолютно неважно на чем реализовывать - Пайтоне, Джаве, ДЛЕ(если  она подпадает под мой паттерн))

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

Не смотрел как в DLE. Но про разные "заметил". Я сторонник разных. Т.е. у модуля или компонента (в общем некоей сущности которую можно подключать) свой набор файлов, по количеству языков. Шаблоны  разные (если это речь про шаблон некоей единицы страницы) нет необходимости. Один шаблон к нему языковых файлов по количеству поддерживаемых языков.

Не совсем понял. Какая разница скинуть  и json и массив в файл нет же сложностей - т.е. организовать редактирование из админки вообще не проблема.  

Кстати, несколько в сторону, но о том же.  В Qt (C++, питон, etc...)  тоже на файлах

Мне удобнее работать с JSON.  Это уже детали реализации, не архитектуры. 

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

Кто бы говорил.. Мега-гуру, который мультиязычность на json делает..

Поверь, нет 😎

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

А можешь привести пример, как это бы работал с массивом? Насколько я понимаю, массив это обьект пхп, который используется в интерпретаторе? Как происходит взаимодействие в таком случае? Как  работать с  json в питоне - я привел.
В чем выгода использования массива?

Флудер от специалиста отличается тем, что он может обосновать свою точку зрения. Раз тебе нечему у меня учиться - докажи свою точку зрения, расскажи о преимуществах твоей реализации данной задачи, приведи пример. Тогда я соглашусь с тобой. 

Прошу прощения, не обратил внимания сразу на вопрос.

Сразу оговорюсь я про PHP.  Самое "простое" пишем массив в файл

<?php
$dict = [
'someKey1' => 'someValue1',
'someKey2' => 'someValue2',
];

Точнее,  если возвратиться к модульности, то

<?php
$dict['someKey1'] = 'someValue1';
$dict['someKey2'] = 'someValue2';

Далее простой include и этот файл(ы) сразу интерпретируется.

В случае json (или любого другого  формата) уже выполняется больше шагов:

1. Читаем файл
2.  json_decode
3. интерпретация

Если не ошибаюсь, в примере было в одном json все  языки,  тут в одном файле только один язык. Это удобнее , на мой взгляд, т.к.:

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

- переводчик трогает только один языковой файл и нет причин проверять, а не сделал ли он чего либо не то в другом языке (что то типа из мира СОЛИД :)  - файл отвечает за, например, китайский, а русский - это зона ответственности другого файла)