Александр Воробьев

Не зарекайтесь ;)    Каждый инструмент служит своим задачам. До и пользоваться надо уметь инструментом. У меня тот же Битрикс не тормозит. Выбор надо делать трезво, нафига делать свои велосипеды если есть  некий инструмент, который покрывает задачу в очень заметной степени - это позволяте сконцентрироваться на том функционале, который для проект является дейстивтельно уникальным.

Ну у меня свой движок просуществовал 15 лет, потом надоело тратить время на то, что понятно как делать, делать не интересно (Есть более интересные задачи)..  Я плюнул на него и совершенно не жалею. Есть у меня, например, мой личный проект, там работы оверхдохрена, нафиг мне отвлекаться на типовой функционал? Или, как пример, как появился закон о кассах, - самому пилить интеграцию... да и те же эквайринговые сервисы интегрировать. я в этом году несколько сервисов перепробовал (в связи  с трудностями приема оплаты из за рубежа).. сам бы на это кучу времени потратил.... 

в общем нет.. пока речь идет о блоге или о чем то простом, в конце концов пока создание этого ядра прокачивает скилы, или является интересной задачей - да хороший проект.... а потом надоедает.

Я конечно не агитирую, просто свое мнение высказал  :)

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

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

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

В принципе крайне редко редактирую что ли бо по ftp (да и вообще на бою). В крайнем случае на серваке vim.

А вообще, когда в редких случаях (т.е. нельзя сказать, что я "собаку съел" в таком кейсе), использую Kate. Конечно пробовал шторм (это основное IDE у меня) - но не пошло. Kate и как системный редактор и, коли уж пошел на ftp из GUI, то просто в менеджере файлов открываю как бы и локально было.

И еще вариант

function day_of_programmer_shortcode(): string
{
    $data = explode(' ', date('Ymd z', mktime(0, month: 9, day: 12)));
    [$date, $number] = array_map('intval', $data);
    if ($number === 255) {
        ++$date;
    }
    if ($date === (int)date('Ymd')) {
        return '<div class="day-of-programmer-message">Поздравляем с Днем программиста!</div>';
    }
    return '';
}

Все, пожалуй пора идти работать, а то завтра в фонтаны нырять....

Как вариант (правда не тестил)

function day_of_programmer_shortcode(): string
{
    $date = mktime(0, month: 9, day: 12);
    if (255 === (int)date('z', $date)) {
        $date += 86400;
    }
    $nextDate = $date + 86400;
    $now = time();
    if ($now >= $date && $now < $nextDate) {
        return '<div class="day-of-programmer-message">Поздравляем с Днем программиста!</div>';
    }
    return '';
}

Еще, кстати, аргумент пришел в голову. Как исходные данные: речь о 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'; 

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

Ну тут конечно на правах ИМХО (по моему скромному мнению).  Это скорее по ощущениям, особенно если json храниться в одну строку. (а стандартная phpшная функция упаковки массива/объекта в json именно в одну строку формирует.)  можно сказать "Основное"  для меня это нет необходимости декодировать и кодировать. т.к. код в конечном итоге все равно с массивом будет работать.

Синтаксис можно проверить повесив валидацию на git хук (в прочем json тоже так же можно обработать). 

Все же мы говорим об интерфейсных текстах, это не контент и тесно связан с кодом. Т.е. все равно будут ситуации подобно: "Ответственный Вася решил что некий интерфейсный текст больше не нужен и грохнул ключ значение из json или массива. А у нас по бизнес логике на конкретном проекте предусмотрено, что для отсутствующих текстов берется из дефолтного языка - в итоге результат будет не такой на какой рассчитал Вася". Т.е. я к тому, что коль уж говорим об интерфейсах, то этот процесс все равно лучше держать под контролем в общем случае.

Опять же, даже если мы забьем на gitхуки и валидацию - есть же обработка ошибок. Перехватили - и дальше поступаем согласно бизнес логики проекта.

Вот на практике проектов: не скажу, что было много мультиязычных, но меняются эти тексты крайне редко. Вот есть проект, где прям часто есть желание, по крайней мере пока, у владельцев "немного поправить". По началу закинул в бд (просто что б задействовать штатные механизмы редактирования контента, чтоб не пилить UI для этого) - в итоге пришли, что "ну нафиг".  За тексты отвечает конкретный работник, не программист, но все  делает четко и без проблем. Правда в админке есть редактор с подсветкой - ошибку сразу видно если что.

Ну тут не совсем так. Ведь в условном текстовом редакторе json править без ошибок сложнее :)  Естественно этот массив не хранится в файле где есть логика. Просто это читать как разновидность "формата хранения текстов" :) Ну, а если прикручивать интерфейс для тех, кто по своим обязанностям имеет право править эти тексты - тут вообще становится пофиг как оно хранится