Closed kdmnk closed 4 years ago
In my humble opinion that would be a contra-productive move. Moving them into a database would cause unnecessary overhead on the database, slowing the site (there must certainly be a reason why [almost] every framework uses localization files). As far as I can tell, this came up in connection with #162, with that in mind, I would suggest that the primary source of strings for the site be the localization files. And for purposes of easing the translation process, copies of the strings could be stored in a database, where they may be edited on a dedicated page. A cron job could also be scheduled that generates the localization files from the database at certain intervals. As far as I know this is popular and prevalent way of handling this situation. This way the benefits of Laravel's built-in localization subsystem and the easy translation process could be enjoyed.
Yes, this is similar to what we are planning to do here.
So the goal of this issue is to:
The goal of #162 is to create the UI based on this process.
I see, however, I still think automated generation of the accepted translations is more convenient.
The translation would be generated automatically, upon successful review, but not via cron jobs. I do not see why they are necessary if we exactly know when we want to run the script.
BTW, thanks @uno20001 for your input, it's much appreciated.
...for easier handling in the future.