Backend configuration support

[Neil Williams]

On Tuesday 23 August 2005 8:31 pm, Neil Williams wrote:
> Another option is to have the translations in the backend itself and build
> an API to bring the translation from the library as part of the
> configuration KvpFrame.

> I'd simply remove the #PCDATA content from the provider tag (and it's
> xml:lang attribute).

> <?xml version="1.0" encoding="UTF-8"?>
> <qofconfig xmlns="http://qof.sourceforge.net/" >
>   <backend name="GnuCash Backend Version 2">
>     <provider xml:lang="en-gb">
>         <option type="gint64" name="file_retention_days">
>             Number of days to retain old copies of the file.
>         </option>
>         <option type="boolean" name="file_compression">
>             Use compressed files or not?
>         </option>
>     </provider>
>   </backend>
> </qofconfig>

Becomes:

<?xml version="1.0" encoding="UTF-8"?>
<qofconfig xmlns="http://qof.sourceforge.net/" >
  <backend name="GnuCash Backend Version 2">
      <option type="gint64" name="file_retention_days" />
      <option type="boolean" name="file_compression" />
  </backend>
</qofconfig>

or:

<?xml version="1.0" encoding="UTF-8"?>
<qofconfig xmlns="http://qof.sourceforge.net/" >
  <backend name="GnuCash Backend Version 2">
      <option type="gint64">file_retention_days</option>
      <option type="boolean">file_compression</option>
  </backend>
</qofconfig>

(with suitable simplification of the schema)

Any preferences?

The KvpFrame will have keys that are the values from the option content / name 
attribute of the (now static, untranslatable) XML.

The value of that key will be of the type specified in the XML - allowing the 
application to retrieve the correct value. It reads the XML to get the name 
of the key and the type of the value at that key.

In a KvpFrame returned by the GnuCash XML v2 backend:

The key "file_retention_days" returns a KVP_TYPE_GINT64 that holds the number 
of days to retain the files.

Maybe if I made the translation a subkey from that name:

name == value of type "type"
name/desc == translated string that describes this option
name/tip == translated string that can be used as a tooltip.

The key "file_retention_days/desc" contains  a KVP_TYPE_STRING containing a 
translated version of "Number of days to retain old copies of the file." 
which is inserted directly from the .po files into the library at runtime. 
(If I can get that to work, don't know yet.)

?

Implicit in that is that the desc and tip values are always KVP_TYPE_STRING 
and that the subkeys to retrieve the values would ALWAYS be named "desc" and 
"tip". Simple #define in the API should suffice.

Thereby, the translations are passed from the backend to the application via 
the KvpFrame and arrive in the application already translated, almost as if 
the strings were static within the application itself.

Naturally, the API will require that no option name contains a forward slash 
as that would cause Kvp problems anyway.

> The XML simply expresses the type and name of the config options supported
> by that backend. The application can then ask for the config data from the
> backend and in that data, the KvpFrame, maybe I can insert the strings so
> that the application *receives* translated strings at runtime, exactly as
> it would from it's own call to gettext.

Thanks for the feedback on this, I hope this simplifies things and provides 
for the required functionality.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050823/b22523ea/attachment.bin