The MessageCatalogue in DatabaseLoader still has no $resource set when created. So the caching will not be triggered to refresh the translations cachefile.
Since this is complete file-based at the moment (symfony-wise), the resource is a file resource and sf watches for changes in timestamp.
A few thoughts:
Since dumping the database content is acceptably fast, we might want to refresh the translations at specific time intervals? But what happens if people use files AND database (vendor translations...)?
If history is completed, we could dump as soon as there's a change in the history table. Therefore we'd need a new type of resource object.
Completely ignore? In my specific case here, we're deploying symfony and every time there's a complete cache build, so all translations are dumped.
Resolution:
[ ] Implement new resource class "DatabaseResource"
[ ] Add resource factory service(?) or possibly use existing one
[ ] save updated-date from latest database entry as resource "filetime" and compare to latest entry on next call
This should keep translation MessageCatalogue in cache as consistent and current as the file-based checks.
The MessageCatalogue in DatabaseLoader still has no $resource set when created. So the caching will not be triggered to refresh the translations cachefile. Since this is complete file-based at the moment (symfony-wise), the resource is a file resource and sf watches for changes in timestamp. A few thoughts:
Resolution:
This should keep translation MessageCatalogue in cache as consistent and current as the file-based checks.