luksan47 / mars

Eötvös Collegium's Unified IT System
MIT License
4 stars 16 forks source link

Move localization files to database #205

Closed kdmnk closed 4 years ago

kdmnk commented 4 years ago

...for easier handling in the future.

uno20001 commented 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.

luksan47 commented 4 years ago

Yes, this is similar to what we are planning to do here.

luksan47 commented 4 years ago

So the goal of this issue is to:

The goal of #162 is to create the UI based on this process.

uno20001 commented 4 years ago

I see, however, I still think automated generation of the accepted translations is more convenient.

luksan47 commented 4 years ago

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.

luksan47 commented 4 years ago

BTW, thanks @uno20001 for your input, it's much appreciated.