Sometimes it’s just one of those days. And sometimes you spend way too much time debugging something that turns out to be a trivial issue.
The Problem
This project was a relatively simple Laravel setup with automatic deployment to Fortrabbit. Translations were done using the built-in localization capabilities, with translation strings in the /lang folder.
During a routine update, I noticed changes in the /lang files were not being displayed. No matter what was changed in the files, the old strings were being displayed. Connecting via SSH onto the server and cating the files confirmed the update was being rolled out, but the changes did not show.
Clearing the cache didn’t help, php artisan cache:clear didn’t change anything, nor did pruning the cached view files (rm -f /storage/framework/views/*.php).
In fact, even skipping the blade output and using Tinker, calling __('namespace.mystring'), was giving old results, not matching what was in the file.
The Cause
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.
The Solution
sshing onto the server, rm -rf /resources/lang.