Jesse++ Translation of SQL files is a bigger project and too difficult for most people starting with Koha. The current system of translating SQL files is error-prone and should be replaced by better methods. It's too easy to forget one file when adding new permissions or system preferences. Changes to the table structure get not reflected in sample files etc. In my opionion the current system for translation of system preferences is a great improvement. Katrin -----Original Message----- From: koha-devel-bounces@lists.koha-community.org on behalf of Jesse Sent: Mon 12.07.2010 19:10 To: Chris Nighswonger Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Moving system preference serialization into thedatabase 2010/7/12 Chris Nighswonger <cnighswonger@foundations.edu>
On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic@tamil.fr> wrote:
As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues.
Isn't it too late?
I'll defer to Galen on that point.
To be translatable you need not to forget to serialize
syspref templates per language, and then:
* modify syspref editor to get YAML data from DB rather than from .pref files, per language * modify translation process (LangInstaller.pm) to extract text from DB and and write into DB
Actually, the present yaml would simply go into a *.sql file under mandatory sysprefs. This would ensure their installation during the initial run of the web installer.
As for translation: The current yaml files should be translated already. This change would only necessitate a one-time move of those files into the previously mentioned *.sql files and their appropriate directories.
Translation into presently un-translated languages would then follow the already established procedures for translating the mandatory, etc. sql files.
It would be very useful to have a complete API to manage sysprefs and allowing to add, modify, update sysprefs, integrated with updatabase.pl process.
Now when we add a new syspref, we have to:
1. Add some text into a .pref file (history in git) 2. Add an INSERT statement to syspref table into kohastructure.sql 3. Modify various default values per language located in installer/data/mysql/<lang>/.../default-syspref.sql 4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT statement.
Any sysprefs modification should aim at simplification. There is room for simplification:
* Clearly distinguish syspref values from a koha instance (stored in DB) and syspref templates (.pref file/db) * Put default values per language directly in .pref file (or DB but how will you track modifications by developers, we have git now) * Delete all perl language default values located in installer/data/mysql... * Delete deprecated fields in syspreferences table: options, explanation, type. And modify accordingly all .sql files.
This process is not aimed at fixing the syspref system for ease of use by developers... sorry, there is definitely not time for that before the 3.2 release. It is simply aimed at restoring a feature which is present in 3.0.x which many users depend on, but is not presently in 3.2.x.
Having said that: this work could certainly form the basis of a solution to those problems encountered by developers when adding sysprefs to areas other than the 'local-use' tab.
Kind Regards, Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
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. 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. 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). Wow, that turned out longer than expected. Anyway, hope I made sense. Sincerely, -- Jesse Weaver