Backend configuration support

Tue Aug 23 15:31:39 EDT 2005

On Tuesday 23 August 2005 12:17 am, Derek Atkins wrote:

(Note: I had a different idea during the course of this email, we may be able 
to solve this as we would all like. My apologies if it therefore seems 
disjointed.)

> I'm trying to wrap my head around where these translations live...

The configuration options are created by the backend developer - whether that 
is in QOF or in GnuCash/CashUtil - depending on whether it is a backend for 
an application (like gnucash xml v2) or for all QOF applications (like QSF).

QOF will be gettext enabled when I decide what options QSF will need. 
Therefore, QSF translations will happen in QOF, using it's own gettext .po 
file (which will be v.v.v.small).

GnuCash XML v2 translations will happen in the gnucash gettext .po file.

Currently this adds all of two strings to the gnucash .po file.
(tested and it works)

> Whether these backends are being part of QOF or part of GnuCash.

Depends. GnuCash XML v2 must stay within GnuCash, it cannot cope with general 
QOF data from applications like GnoTime or PilotQOF. As such, the translation 
lives within GnuCash.

QSF is generic and can cope with any QOF data, therefore it can live in QOF.

I'll have to see if I need to call gettext as part of the library init routine 
as the backend library will not be open when main() executes the call to 
gettext in the application. This applies to all backends because they will 
only be opened using dlopen().

> A large part of me thinks that the translations belong with the
> Application,

They do and in the case of the GnuCash XML v2 backend, they will. The problem 
is that the application doesn't know anything about the options at compile 
time - it can't if you want a generic backend loader configuration dialog. It 
has to get that information from the backend.

> which means you don't want the translations in the XML 
> file, but in the gettext .po file.

I think you've misunderstood the process, perhaps, because the translations 
ARE in the gettext .po file, it's just that there is an intermediary step 
because we can't modify the XML directly with gettext.

1. Create the config options.

2. Document the options IN PERL which puts the translations into the 
gettext .po file for that application (or for QOF in relation to QSF). This 
happens because of the change I've committed to make_gnucash_potfiles.in 
which now adds .pl files to the list of files to check for translatable 
strings.

3. The po files are translated as normal, including the added strings from the 
GnuCash XML v2 backend configuration options.

4. Run the perl to pick up the translations from the gettext files according 
to the *locale of the system running the perl script*.

That's where I have a problem because the perl script is currently expected to 
be run by the maintainer.

Hence, I was wondering if AFTER translation in the gettext .po files, but 
prior to release, if there was some way of building an installable XML file 
that incorporate all translated versions.

It could be as simple as an iterative loop over each of the locales supported 
to pull that translation from the gettext files and build the single XML file 
that way. The translations live in the .po files but are simply copied into 
the XML to make them available to the process.

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.

Hmmm, why didn't I think of that before?

If that works, we won't need any translated strings in the XML or Perl.

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.

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

> If it's living in QOF...  I'm not sure I like that..  But I still
> don't think it should live in the XML.

The translations live in .po - no matter what.

No XML exists until the perl script is run.

OTOH, if my new idea works, we won't need the perl at all, the backend 
developer can write the XML directly as it won't use translatable strings.

> > I'm not sure if the perl is going to have to be distributed - at present,
> > gettext cannot alter the XML itself, only the perl (which needs the
> > gettext module). This makes it hard to use gettext as intended, at the
> > user end. One alternative is to use the translations to build a single
> > XML file that includes all translations.

So:

1. The perl script is distributed and run during installation on the user 
system. It picks up the locale from there and inserts the translations into 
the XML. Problem: Not everyone will have the perl gettext module installed. 
It's a bit of an odd dependency.

OR

2. The perl script is modified to generate a single XML file at release time 
that contains translated strings from the gettext .po files - one set per 
supported locale. This will result in a larger XML file but not significant. 
The single XML file containing all translated strings will then be read using 
libxml2 which can easily pick out the locale required for the current 
instance at runtime.

OR

3. The idea I had whilst writing this reply - passing the translated strings 
from the library and only having the option type and option name in the XML - 
which are not translatable. This also answers Christian's valid point about 
tooltips - those would also be passed in the frame.

I'll investigate #3.

I'm open to ideas!

-- 

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/af3b831d/attachment.bin