In fact, even skipping the blade output and using Tinker, calling __('namespace.mystring')
, was giving old results, not matching what was in the file.
This was an interesting combination of two design decisions, both on the part of Laravel and the host Fortrabbit.
Laravel, up until version 8, stored its localisation files in /resources/lang
.
With version 9, this was moved to /lang
, and so the change was also done in our project.
An interesting decision made in this change can be seen in \Illuminate\Foundation\Application
’s bindPathsInContainer
method:
$this->useLangPath(value(function () {
if (is_dir($directory = $this->resourcePath('lang'))) {
return $directory;
}
return $this->basePath('lang');
}));
(The logic has been originally implemented here, still in Laravel 8.)
This means Laravel will use the old folder /resources/lang
and only fall back to /lang
if it doesn’t exist.
That is unexpected behaviour, but by itself would’ve not done any harm - the whole folder had been moved, after all.
It only became a problem in combination with the way Fortrabbit handles updates via git.
Fortrabbit utilised an „overwrite, but don’t delete“ strategy. This means any files changed or added via git will be added to the server, but Fortrabbit never deletes any files, even if they’ve been deleted via git.
This caused the old folder with deprecated translation strings to be still present on the server, and the new translations being ignored.
ssh
ing onto the server, rm -rf /resources/lang
.