[Koha-devel] Moving system preference serialization into the database

[Joe Atzberger]

I'm also against translating SQL when templated techniques are feasible.
 But if the feature needed is to allow staff users the ability to enter
multiple translations *at runtime* with no systems-level administration,
then the only question is whether to allow Koha to:

   1. write to a directory that it later uses for data, or
   2. put more stuff in the database.


The former case would also change the security profile of Koha
significantly.  Allowing your application to write to template directories
is bad practice.  Among other things, if you happen to be running your Koha
installations off of git repos (as I know several vendors do), then having
new uncommitted changes in the repo will *block* git pull/rebase for
updates.  I regard it as inadvisable.

The latter is also undesirable, but only because we are talking about trying
to translate SQL, and for the reasons Frederic points out having to do with
translation.  Therefore the fix is to do something like allowing to Koha to
ingest values from a template file at install and runtime.  Read the
template (doesn't have to be H:T:P, as long as we can get PO files from it),
parse it to whatever, match against keys in the syspref table and update
description.

I should say that I am unconcerned with translation of descriptions for
purely local use variables if the user can control the description field in
the DB.  They can write the description in as many languages as they need.
 For standard sysprefs that need to be translated, I would still want to
route everything through http://translate.koha-community.org/ .  This might
mean a longer turnaround to get the result onto a production system, but it
certainly would lead to better satisfaction with Koha for other users of the
same language.

--joe

On Mon, Jul 12, 2010 at 2:07 PM, Frederic Demians <frederic at tamil.fr> wrote:

>
>  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.
>>
>
> Yes, even if it's not so simple, for XSL files and for .pref files, because
> they were designed at first with no specific consideration for localization.
> See various bugs related to this.
>
>
>  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.
>>
>
> As I understand it, the main issue is with blocker bug 3756. It could be
> solved without adding a new syspref table column. You get from all the .pref
> files a list of 'official' sysprefs and you compare it to defined sysprefs
> in DB: the difference are the local sysprefs.
>
> --
> Frédéric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/82be68fe/attachment-0001.htm>