translations and option definitions

[Neil Williams]

On Saturday 03 September 2005 10:34 pm, Christian Stimming wrote:
> Ok, now let's clear up this translation problem. 

It is getting better with these new functions:

typedef struct QofBackendOption_s {
	KvpValueType type;
	const char *option_name;
	const char *description;
	const char *tooltip;
	gpointer value;
}QofBackendOption;

void qof_backend_prepare_frame(QofBackend *be);

void qof_backend_prepare_option(QofBackend *be, QofBackendOption *option);

KvpFrame* qof_backend_complete_frame(QofBackend *be);

typedef void (*QofBackendOptionCB)(QofBackendOption*, gpointer data);

> Here's what I understood 
> about these obnoxious :-) data-store-backend options: Eventually, the
> backend options should be passed as a kvp_frame. The collection of all
> options is a kvp_frame with all options as sub-kvp_frames. For each option,
> there is a name which is the path to that kvp_value. Each option has a type
> which is implicitly defined by the type of that kvp_value. (Note: You
> really need to do something about boolean options! Either add a "gboolean"
> kvp_value or decide on a fixed convention.)

There's been a need for a KVP_TYPE_BOOLEAN for some time. I will look at it. 
Temporarily, I'll continue with "TRUE" or "FALSE" as strings. 
(untranslated!):-)

> Each option has a 
> human-readable string containing the description of it. And an option also
> has a human-readable tooltip string.

Yes. I've been doing some work on this in the meantime:

>   kvp_frame *my_options = from_somewhere(blabla);

QofBackend *be;
be->backend_configuration

> The human-readable strings are english. Now let's translate them. If I
> already know that the string is located at "firstoption/description", then
> this is done by
>
>   kvp_frame_set_string(my_options, "firstoption/description",
>     gettext(kvp_frame_get_string(my_options, "firstoption/description") )

Yes, done that.

qof_backend_prepare_frame(be);
option->option_name = GNC_BE_DAYS;
option->description = _("Number of days to retain old files");
option->tooltip = _("GnuCash keeps backups of old files, "
	"this setting dictates how long each is kept");
etc.
qof_backend_prepare_option(be, option);
return qof_backend_complete_frame(be);

> and that's it. Conveniently the macro _() is defined as an alias for
> gettext(), so writing _(kvp_frame_get_string...) is just the same. It
> should be clear how to achieve this in a generic form by
> kvp_frame_for_each_slot() and so on.

Doing that now.

> The only other part that has to be ensured is that *at compile time* the
> original english strings need to be found by the xgettext program so that
> they will appear in po/gnucash.pot as a so-called "msgid". *If* a string is
> in a C source file *and* it is enclosed by _() then xgettext will
> automatically add that string as msgid.

Done: see the option preparation above.

> Back to the option definition and translations. If the option definition is
> done inside a C source file, very well, then the msgids will simply be
> retrieved by xgettext from that C source file. 

I've decided to implement this. It's just a case of making a usable method of 
retrieving the option details OUT of the frame. kvp_frame_for_each_slot isn't 
recursive so I'm just putting together a foreach that will take the frame and 
return the options one at a time.

> There is only one open question: Which package should have these strings in
> its .pot file, i.e. in which pot file should the msgids eventually be
> located? That question is easily answered: If the string will be displayed
> in the Gnucash GUI, then it *has* to appear in gnucash's own pot file.

Not exclusively the gnucash po file. By calling gettext on the library *as it 
is loaded* by whichever application uses it, the translations from 
gnucash-gui or cashutil are used. It does mean gnucash-gui and cashutil po 
files need to be built from the same source tree.

> Gnucash has so much more translators and translations than any other
> involved project. Any translations of strings in Gnucash simply *have* to
> be located in gnucash's own gnucash.pot. 

But CashUtil needs them too. It already has all the QofBackendError messages 
re-formatted for a CLI output (with less \n and a standardised "%s:", PACKAGE 
start to each message).

By having CashUtil in the GnuCash CVS tree I'm hoping that the majority of 
translations will also be available for CashUtil. To install them separately 
and because the CLI has radically different formatting requirements, these 
will need to be separate po files.

> So if these option strings are to 
> be displayed in a gnucash GUI dialog then they have to be translated by the
> gnucash pot file as well.

True. And CashUtil.

> However, this only means that the msgid somehow 
> have to appear in the gnucash pot file 

Easily done now that the strings are in the C files in the one source tree 
that will eventually provide both GnuCash-GUI and CashUtil.

-- 

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