[Koha-devel] Moving system preference serialization into thedatabase

[Fischer, Katrin]

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 at lists.koha-community.org on behalf of Jesse
Sent: Mon 12.07.2010 19:10
To: Chris Nighswonger
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Moving system preference serialization into thedatabase
 
2010/7/12 Chris Nighswonger <cnighswonger at foundations.edu>

> On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/971c7f21/attachment.htm>