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@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