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

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

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

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

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

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

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