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

И еще вариант

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

Можете озвучить характеристики и условия стенда?  "намного" это сколько?  

Еще раз повторю: попробуйте все на практике. Не на сайте с посещаемостью "ты, да я, да мы с тобой". А на сайте на котором есть посетители. И который имеет контент.  

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

Просто внимательно посмотрите трезво на фреймворк свой, вы там тоже пользуетесь файлами, более того суете в xml то, что потом приходится "если грубо" преобразовывать в PHP - и при этом считаете его мего быстрым и не жрущим ресурсы, а тут простой инклуд, по вашему убивает память..... смешно. где логика то?

Кстати, вот выше в пояснении нашему суперразарбу вспомнился еще один  аргумент в пользу файлов содержащих простые массивы. Аргумент правда касается PHP, в питоне не смотрел как устроено в этом плане.  В итоге у меня получается обычный PHP код, который, как я полагаю (глубоко я в механизм работы OpCahce не погружался) так же как и прочий постоянно используемый код один раз парсится и уже хранится в памяти в виде опкодов.

Попробуйте все это на практике. У меня есть сайты которые спокойно живут на хостингах с 2 гигами оперативки. (при этом активно используется кеширование для подготовленных данных)  Далее, что значит обрабатывается.? Вы выше мой код видели? Какие там переменные создаются - идет сразу работа с переменными. К тому же в нормальной ситуации работает opcache - который кеширует опкоды. В случае подключения массива это простой статичный и даже без ветвления php код.  Идем далее современные фреймворки это много файлов. Даже ваш, который еще совсем не оброс функционалом (даже для простейшего из типичных ныне сайтов) уже достаточно много файлов. И там несколько дополнительных файлов - капля в море.  Кстати, я не вдавался в подробности ка креализовано у вас, но вы божились, что css у вас только нужный подключается на каждой странице в заисимости от ситуации и даже для этого есть у вас специальные опции... Чтож вы  css то не втащили в базу? Собственно и xml храните в базе - у вас вообще тогда по вашей теории сайты реактивными станут. :)

Естественно. Ваши мысли не подтверждают ни практика, ни то как работают те или иные сервисы (в т.ч. СУБД).

Изучите уже как работает СУБД. Вы даже не поняли о чем я написал.  Уточню, этот кеш, о котором я сказал, регламентируется и управляется СУБД. Из кода я на него не влияю.  Далее интерфейсные языковые фразы это то, что требуется всегда,  т.е. это "часто  запрашиваемые данные". Т.е. даже по вашим словам они будут  в памяти.