On Mon, Jul 12, 2010 at 1:10 PM, Jesse <pianohacker@gmail.com> wrote:
There were two important reasons for moving the system preference descriptions out of the database.
The first was translation. Translating strings in the SQL files is significantly different than the rest of the translator's workflow (from what I can tell), and requires several skills that Pootle does not. The easiest way to tell this is to look at how many languages have translated interfaces, and how few have translated system preferences. Besides the main targets, en-US and fr-FR, there are only four others that had a translated sysprefs.sql, thanks to the work of Katrin and others. Not many are going to waltz into the Koha project with both good translation skills and enough bravery to translate the SQL. Localizing system preference defaults per-language makes sense, definitely. With the current file-based system, this is separated from translation, and is a much less daunting task than having to translate and localize an SQL file at the same time.
Based on this and Katrin's subsequent reply, I certainly will not argue this point.
Aside from that issue, keeping the two separate was also a very intentional separation of concerns. Aside from the previously-mentioned translation problems, putting interface-related strings in the database is bad practice, IMO. Any practical concerns are important, but I think the current system has this on its side. Today's nitpicky theoretical problems are tomorrow's intractable real-life bugs (fines system, anyone?).
Under the old system, fixing any issues with the system preference display required a database update, no matter how trivial they were. This made little to no sense, considering that these were entirely interface issues. Again, you could create a system to keep the data files and DB in sync without this, but this would be at best confusing and at worse fragile.
Leaving the files where they are makes it clearer that they are intended to be interface-related data, like the XSLT, and translated as such.
I am not utterly opposed to leaving the system as it is if that is the prevailing opinion. As for the fix for the current and future problem however....
My vote for solving the local-use preferences system is to leave the current system as it is, but add a database column or some way of easily distinguishing local-use from non-local-use prefs in the DB (making the explanation column NULL for non-local-use would work, though would require a time-consuming database update). This would make building a local-use tab fairly easy.
Once we do that, we can drop the options column entirely, as I doubt most local-use users will care enough to set it. Theoretically, we could even drop the type column, though that might be useful in the future to help deal with more complex types of system preferences (automatically turning date sysprefs into C4::Dates objects, for example).
Unless no code depends on the type column, I think we should leave it alone for the moment. In the long haul, the table could certainly be cleaned up. The singular problem with local-use sysprefs in the system as it presently stands is the matter of setting the file permissions on the *.pref files. In order for those files to be written from within Koha, the apache user must have write permissions to those files. This is, in theory, a very simple fix. Just fixup Makefile.PL and company to modify the permissions accordingly. It is, in practice, a small nightmare for anyone who is not intimately acquainted with the how's, why's, and wherefore's of this group of scripts. So we need a volunteer... anyone? (Well, this job of writing to files from within Koha will have to be done sooner or later, but maybe later is better.) ;-) A syspref editor working with the syspref system currently in place is really a trivial thing to create. I see no reason to handle local-use prefs any differently than other prefs. Doing so would only complicate things imho. The code I have written so far already serializes new prefs, writes them to the local-use.pref file, and adds the proper data to the systempreferences table. It is in the rough, but clearly demonstrates the possibility of having a working pref editor in the 3.2 release. Given the relative ease with which a permanent solution maybe had, I'd hate to see us resort to a hack to fix bug 3756. Plus, any solution which stores local-use prefs in the db and does not serialize them makes for yet more work when a permanent solution is implemented. Not to mention all of the inherent risks of updatedatabase.pl munging data as it reorganizes it. Kind Regards, Chris