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