Да. Сам недавно столкнулся с этой проблемой, решается тривиально, если вещь хостится на линуксе, но возникают проблемы, если на винде.
Для начала, в том месте где ты делаешь
app()->setLocale() нужно дополнительно вызывать нативную функцию php для изменения локали:
setlocale(LC_ALL, $locale . '.utf-8', $locale_CODE . '.utf-8', $locale, $locale_CODE);
Тут:
$locale === 'ru'$locale_CODE === 'ru_RU'
Но помни, что в ОС на которой хостится проект должны быть соответствующие локали.
Далее, если
$article->created_at возвращает
Carbonобъект, то вместо
format() нужно вызывать
$article->created_at->formatLocalized();
Для удобства можно поместить это преобразование в аксессор, если нужно.
Я надеюсь, ты используешь utf-8. И с этим могут быть проблемы если проект хостится на винде, как я уже говорил выше. Дело в том, что не всегда на борту имеются кириллические локали в utf-8, и единственный способ, который можно использовать не прибегая к танцам вокруг ОС (то есть так, чтобы проект можно было без боли развернуть в любой среде) - это обернуть возвращаемое значение в iconv(). В том-же аксессоре, например.
Пример реализации аксессора:
public function getСreatedAtAttribute($value){
return iconv('cp1251', 'utf-8', Carbon::parse($value)->formatLocalized("%d %B %Y"));
}
Но возможно будут проблемы, если в системе все-таки есть соответствующая UTF-8 локаль, но тут поведение iconv абсолютно непредсказуемо - у меня бывали случаи, когда преобразование в таком случае не происходило, и все было хорошо, а бывало что если кодировка уже правильная, то iconv ломала все к чертям собачьим и возвращала нечитаемые кракозябры.
Простой