Clear the config cache and get happy

[Crazykriz]

Hi all,

this is not a classic issue about a bug but more a hint for developers using this localization library. I hope the hint will be useful for all who are getting nuts with a nasty "problem" which encountered me today and took me hours to "solve". It's about the config cache of Laravel which holds a representation of the whole Laravel configuration files to speed up config accessings.

Well, I tried to add a new messages file to the language folders in resources/lang (Laravel 5.7) and also added the name of the new message file to the config's messages array. I called Artisan to rebuild messages.js and voilá... nothing happened, the new translations had been skipped. This was somewhat creepy as I added new messages files yesterday and everything was fine. After retrying this procedure for hours, debugging the sources and oiling the chainsaw I found that the JS generator script did not load the most recent edition of the localization-js.php file but got his data from the config cache. Oh dude...

Ok, so just clear the config cache of Laravel (php artisan config:cache). rebuild your messages.js file and finally the new translations will be available.

Hopefully this hint may help other people to avoid such "afternoon fun" ;-)

Regards
Crazykriz

[rmariuzzo]

I appreciate a lot for sharing this. I could include a note in the readme file. Also, do you think we can do something better in this package?

…

On Thu, Jun 13, 2019, 13:50 Crazykriz ***@***.***> wrote: Hi all, this is not a classic issue about a bug but more a hint for developers using this localization library. I hope the hint will be useful for all who are getting nuts with a nasty "problem" which encountered me today and took me hours to "solve". It's about the config cache of Laravel which holds a representation of the whole Laravel configuration files to speed up config accessings. Well, I tried to add a new messages file to the language folders in resources/lang (Laravel 5.7) and also added the name of the new message file to the config's messages array. I called Artisan to rebuild messages.js and voilá... nothing happened, the new translations had been skipped. This was somewhat creepy as I added new messages files yesterday and everything was fine. After retrying this procedure for hours, debugging the sources and oiling the chainsaw I found that the JS generator script did not load the most recent edition of the localization-js.php file but got his data from the config cache. Oh dude... Ok, so just clear the config cache of Laravel (php artisan config:cache). rebuild your messages.js file and finally the new translations will be available. Hopefully this hint may help other people to avoid such "afternoon fun" ;-) Regards Crazykriz — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#132?email_source=notifications&email_token=AADLMH66S7XM4UGJ5S6SN7LP2KCFNA5CNFSM4HX4MRXKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZMCPYQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADLMH2U73OA4YFWAMZRZXTP2KCFNANCNFSM4HX4MRXA> .

[Crazykriz]

Hi Rubens,

this would be fine if you could add this to the readme file.

Talking about improvements I started to add the package "spatie/laravel-translation-loader" from well-known dev team Spatie. This package puts translations to data base and deals both sources files and data base simultaneously where the files are used as fallback source then if the translation cannot be found on data base. That means that your package will look up only the files which are now fallback only and would ignore the data base which could contain more recent translations.

I quickly came to the conclusion that this solution doesn't fit my need because I need a more complex data base table than this one provided by Spatie. I think I have to implement my own service provider which can synchronize the data base with the messages files and forces your package to update the JS translations then...

But it's ok as I currently use the messages files only and ignore the Spatie data base table. With other words I don't have any ideas for package improvements ;-)

Regards
Crazykriz

[Crazykriz]

Ok, just to get to an end of this topic I recommend to clear the Laravel config cache as often as necessary. When committing stuff I can monitor in my IDE whether the messages.js file is in the list of files to be committed or not. Most times it's not after updating the translations.

So Rubens, if you need a real package improvement, just offer the audience the possibility to flush the config cache automatically before messages compilation starts. Maybe you can implement a new flag which explicitly deactivates the config clearing - so it would be activated by default. What do you think?